Hi
I am trying to get to grips with the mini demo board. So far I can only plug in to the USB port and communicate with VSOS via TeraTerm.
The 'Dir' command returns only drives D,I,R & S. There does not seem to be a SPI flash even though there is one on the board. There is almost no basic information regarding this board. (Such as what SW1 does) I cannot get the Hello.Mp3 file to play I just get a click in the headphones and the system seems to hang and require a reset.
When I try to use VSIDE the target device does not show up, neither does it in windows explorer.
I am using Windows 10 Home edition version 20H2 on a laptop.
Do I need any special drivers?
Is there a patch file for the VS1010D? If so where can I find it?
Do I need to buy a Uart-USB lead from you?
As a demo board this is not very impressive at the moment!
mini demo board
Re: mini demo board
Hello and welcome to the forum.
Due to ROM bug the procedure to make SPI flash S: drive isn't totally straight forward.
and there are no special requirements for USB-UART cable. Any 3V3 level cable able to run 115200 will work just fine.
So what are you planning to do with VS1010? I probably know the pitfalls and remember the threads to link where someone else has had same problems.
Anyway I'll take your input and put to my not even close to be ready project: "- Write manual for minidemoboard" and take a look if I can fix the audio when using USB console mode.
Only USB? As the board boots to the USB serial port mode if there isn't the jumper in place. Other mode is runlevel 15.
The flash is empty and to show up as device, it needs to be formatted to FAT file system. However it should be detected. Below is copy of UART messages from booting to runlevel 4 which will show the SPI flash as USB mass media.board.The 'Dir' command returns only drives D,I,R & S. There does not seem to be a SPI flash even though there is one on the board. There is almost no basic information regarding this board.
Code: Select all
VS1010>reboot 4
C#0d1d at runlevel 4
VS1010D VSOS 4.20
Files:6. Buffers:3.
Runlevel 4
SPIF:c217, 16384K
SD:942 MiB
VS1010D patch SPI flash write
Relocked (3007)
- Run reboot 2 (SD-card to USB mass storage)
- Copy boot.dlx to the root of the SD card
- Create sys directory
- Safely remove from USB
- Reset VS1010 to console
- Run reboot 4 (SPI flash to USB mass storage)
- Format the SPI flash to FAT
- Copy boot.dlx to root of the SPI flash
- Write your CONFIG.TXT
- Create sys directory
- Copy your firmware files to sys/
- Safely remove USB
- Reset
- Enjoy
Prevent SPI boot. Really nice feature when you have bricked the SPI flash.(Such as what SW1 does)
I think I have seen this problem before when working with USB console. Personally I think it is great feature but during development every time I reset the chip my terminal drops and it is really annoying.I cannot get the Hello.Mp3 file to play I just get a click in the headphones and the system seems to hang and require a reset.
reboot 2 or reboot 14 ? that should reboot the system and show the SD card. Then the program can be copied or let VSIDE to do that by defining target drive with the rightmost button from build group. VSIDE won't create SYS directory so you have to create first by hand.When I try to use VSIDE the target device does not show up, neither does it in windows explorer.
No special drivers, the boot.dlx patch is here: viewtopic.php?f=15&t=2620I am using Windows 10 Home edition version 20H2 on a laptop.
Do I need any special drivers?
Is there a patch file for the VS1010D? If so where can I find it?
Do I need to buy a Uart-USB lead from you?
As a demo board this is not very impressive at the moment!
and there are no special requirements for USB-UART cable. Any 3V3 level cable able to run 115200 will work just fine.
So what are you planning to do with VS1010? I probably know the pitfalls and remember the threads to link where someone else has had same problems.
Anyway I'll take your input and put to my not even close to be ready project: "- Write manual for minidemoboard" and take a look if I can fix the audio when using USB console mode.
Re: mini demo board
Thanks Hannu
I have been on holiday so have not had any time to work on this, so sorry for taking so long to reply.
Just for information, I am wanting to make a 'stomp box' which senses a Piezo and triggers a short audio track.
This will be for bands playing gigs.
Regards
S
I have been on holiday so have not had any time to work on this, so sorry for taking so long to reply.
Just for information, I am wanting to make a 'stomp box' which senses a Piezo and triggers a short audio track.
This will be for bands playing gigs.
Regards
S
Re: mini demo board
That sounds like a reasonable project.
Piezos are nasty little creatures. They are analog, noisy, have high output impedance and can give really high voltages. So keep that in mind when developing your circuit.
But aside from that, you can develop your code with minidemoboard for single input by using the boot disable button. when pressed, xcs0 goes down, we could play from SD card but not from SPI flash.
When it rises, SPI flash access is possible. Here you might want to have some delay to filter out switching. In real product with some better I/O pin you don't need that.
I made quick and dirty patch for you. This has both fixes. SPI write and usb and dac fix so you don't gert stuck on small things like development environment not working 
So put the boot.dlx to your root of your boot device.
Piezos are nasty little creatures. They are analog, noisy, have high output impedance and can give really high voltages. So keep that in mind when developing your circuit.
But aside from that, you can develop your code with minidemoboard for single input by using the boot disable button. when pressed, xcs0 goes down, we could play from SD card but not from SPI flash.
When it rises, SPI flash access is possible. Here you might want to have some delay to filter out switching. In real product with some better I/O pin you don't need that.
Code: Select all
GpioSetAsInput(PIN_XCS0);
DelayL(100000);
while(GpioReadPin(PIN_XCS0)); /* It's high */
DelayL(100000);
while(GpioReadPin(PIN_XCS0) == 0); /* It's low */
DelayL(100000);
shellcmd("play", "R:hello.mp3");

So put the boot.dlx to your root of your boot device.
- Attachments
-
- boot.dlx
- boot.dlx patch file. First big memory hog try
- (2.61 KiB) Downloaded 52 times
-
- patch_spi_write_usb_serial_and_audio.zip
- Patch solution for SPI write and USB audio while USB serial console. First big try
- (78.25 KiB) Downloaded 55 times
Re: mini demo board
Many Thanks Hannu
I am now getting somewhere. Your code snippets worked well. I can trigger a file using the SPI button and access both the SPI and the SD from my PC
Is there anywhere I can find a definitive VSIDE library function reference for the VS1010?
I notice you used the function GpioSetAsInput() which is pretty much self explanatory, but I did have to define the constant PIN_XCS0 because this was not defined in any of the headers I had included.
I have the VS1053 reference but this does not include the function above.
Are all the prototypes for these functions contained within any one header file? If so which one?
Being new to this type of device I do not know what functions are available.
For example, I tried GpioSetAsOutput() but this would appear not to be function as the compiler rejected it.
Best regards
S
I am now getting somewhere. Your code snippets worked well. I can trigger a file using the SPI button and access both the SPI and the SD from my PC
Is there anywhere I can find a definitive VSIDE library function reference for the VS1010?
I notice you used the function GpioSetAsInput() which is pretty much self explanatory, but I did have to define the constant PIN_XCS0 because this was not defined in any of the headers I had included.
I have the VS1053 reference but this does not include the function above.
Are all the prototypes for these functions contained within any one header file? If so which one?
Being new to this type of device I do not know what functions are available.
For example, I tried GpioSetAsOutput() but this would appear not to be function as the compiler rejected it.
Best regards
S
Re: mini demo board
Sorry, I don't have a good straight answer this time. But I have some workarounds and tips how to make life easier.
One neat trick, which is my favourite feature of VSIDE:
CTRL-Shift-F, find what: XCS0 and library find. You should get hits from vs1010_pins.h header file. The search is really greedy and most of the time searching something related it finds from the header comments. And same thing for GpioSetPin() could be found vo_gpio.h
There isn't a full reference. Some header files have good documentation and others not so good. Also just browsing through the header files can give idea what they have. Go to #include <vo_stdio.h> Right click the vo_stdio, open in editor and then click the open and it should show the libvs1010 directory where there are all include files. Beware that modifying and saving the header files is possible and it could break the environment if you accidentally save some garbage to them.
When I write something new, I usually take a look at ROM sources if there is something usable. The VS1010Public can be open in another VSIDE session and CTR-Shift-F is used frequently. However it is compact and efficient code and not the most readable one.
Also many times there is some sample code which uses the specific peripheral and when seeing how it used in one project, it can be adapted to your own code.
Also VS1005 roots and sources package has solutions for VS1005. Many times I use those codes as example and implement the logic of those things. But VS1005 is different chip and HW dependent code wouldn't compile or it would do strange things.
After that I try to search some standard function and read the man page from Linux. And last resort is to just write it. First iteration usually is huge pile of if-elses and then it comes more compact. For compacting the build output is your friend. The last line: "Total words: I 514, X 871, Y 0." shows instruction, X and Y memory usage.
One neat trick, which is my favourite feature of VSIDE:
CTRL-Shift-F, find what: XCS0 and library find. You should get hits from vs1010_pins.h header file. The search is really greedy and most of the time searching something related it finds from the header comments. And same thing for GpioSetPin() could be found vo_gpio.h
There isn't a full reference. Some header files have good documentation and others not so good. Also just browsing through the header files can give idea what they have. Go to #include <vo_stdio.h> Right click the vo_stdio, open in editor and then click the open and it should show the libvs1010 directory where there are all include files. Beware that modifying and saving the header files is possible and it could break the environment if you accidentally save some garbage to them.
When I write something new, I usually take a look at ROM sources if there is something usable. The VS1010Public can be open in another VSIDE session and CTR-Shift-F is used frequently. However it is compact and efficient code and not the most readable one.
Also many times there is some sample code which uses the specific peripheral and when seeing how it used in one project, it can be adapted to your own code.
Also VS1005 roots and sources package has solutions for VS1005. Many times I use those codes as example and implement the logic of those things. But VS1005 is different chip and HW dependent code wouldn't compile or it would do strange things.
After that I try to search some standard function and read the man page from Linux. And last resort is to just write it. First iteration usually is huge pile of if-elses and then it comes more compact. For compacting the build output is your friend. The last line: "Total words: I 514, X 871, Y 0." shows instruction, X and Y memory usage.
Re: mini demo board
SetGpioPin() puts the pin to output mode automatically.
Myself, I tend to access the GPIO hardware registers directly (MODE, DDR, IDATA, ODATA, SET_MASK and CLEAR_MASK) using the PERIP() macro, so I know exactly what happens, but that's just me...
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook
Re: mini demo board
Hi
Many thanks for your reply
As part of my project I want to drive two LEDs from GPIO pins
I cannot seem to find any information on the sink/source capability of the GPIO pins in the VS1010 data sheet.
Please would you let me know what this spec is?
I notice the developer board has two LEDs driven directly, are these low current devices?
Thanks
S
Many thanks for your reply
As part of my project I want to drive two LEDs from GPIO pins
I cannot seem to find any information on the sink/source capability of the GPIO pins in the VS1010 data sheet.
Please would you let me know what this spec is?
I notice the developer board has two LEDs driven directly, are these low current devices?
Thanks
S
Re: mini demo board
There isn't a spec available. Total static consumption is tested to 30 mA and max is given as 60 mA With 42 GPIO pins available and sharing that limit, it isn't much for each pin. I would recommend to keep the currents on about 1 mA level.
On developer board there are 330 ohm resistors. 3.3 V - 1.6 V = 1.7 V and 1.7 V / 330 ohm = about 5 mA Which probably makes those two LEDs biggest IOVDD load on the dev board.
I would use 1k resistor in series with LEDs. And maybe go even higher value and use super bright LEDs so that the LEDs wouldn't be blinding bright. If more current is needed, add FET to drive the LED from your power supply.
On developer board there are 330 ohm resistors. 3.3 V - 1.6 V = 1.7 V and 1.7 V / 330 ohm = about 5 mA Which probably makes those two LEDs biggest IOVDD load on the dev board.
I would use 1k resistor in series with LEDs. And maybe go even higher value and use super bright LEDs so that the LEDs wouldn't be blinding bright. If more current is needed, add FET to drive the LED from your power supply.
Running code after reboot 14
Hi
I am using a VS1010D
For my project I want to initially boot into Run Level 15
The Config.txt file then runs a short code which detects which power source has caused the boot. (Battery or USB)
It then reboots to either Run Level 6 or Run Level 14
The Config.txt file then tries to run different code for each Run Level
My Problem is :- this works for Run Level 6 but not for Run Level 14.
At the moment the only thing the individual programs do is simply flash an LED. (basically the same code)
Both the Run Level 6 and 14 code work if called from the console but only one works if called from the Config.txt file.
I notice in the VS1010 handbook, table 2, none of the USB Run Levels have a Config.txt value. (e.g. [>] for Run Level 14)
Is it possible to get code to run after a level 14 reboot? If so how please?
I would be greatful for you insight!
Many thanks, S
I am using a VS1010D
For my project I want to initially boot into Run Level 15
The Config.txt file then runs a short code which detects which power source has caused the boot. (Battery or USB)
It then reboots to either Run Level 6 or Run Level 14
The Config.txt file then tries to run different code for each Run Level
My Problem is :- this works for Run Level 6 but not for Run Level 14.
At the moment the only thing the individual programs do is simply flash an LED. (basically the same code)
Both the Run Level 6 and 14 code work if called from the console but only one works if called from the Config.txt file.
I notice in the VS1010 handbook, table 2, none of the USB Run Levels have a Config.txt value. (e.g. [>] for Run Level 14)
Is it possible to get code to run after a level 14 reboot? If so how please?
I would be greatful for you insight!
Many thanks, S