Production programming using SPI Flash as program memory

Designing hardware and software for systems that use the VS1010 MP3 Audio DSP Microcontroller.
regh
Senior User
Posts: 39
Joined: Thu 2020-11-05 13:50

Production programming using SPI Flash as program memory

Post by regh »

Hi folks

Our current system is planning to use just SPI Flash for program memory and not have any connector for SD cards to try to minimise the cost of the product. Does anyone have any recommendations for how to program the SPI flash in production? I know there is the flshtool thread viewtopic.php?f=15&t=2630 but this requires an SD card to copy from.

Any advice is appreciated.
Hannu
Senior User
Posts: 158
Joined: Mon 2016-05-30 11:54

Re: Production programming using SPI Flash as program memory

Post by Hannu »

Hi!

Basic programming would go like this with dlx programs in SYS directory:
  1. Get to the console
  2. Send command "reboot 4"
  3. Create filesystem to the USB mass storage device
  4. Attach USB mass storage to your file system
  5. Copy your firmware
  6. Remove the USB mass storage
  7. Reset and your firmware should run.
This would work on Windows environment as it doesn't trigger the SPI flash bug. On Linux the format and and copy could be worked around with copying disk image with dd. In the production firmware the patch.dlx should be present if there is ever going to happen flash writing.

And also there is the VS1010 external flash prommer, which can write to external flash. It may be slower than USB and I haven't used it recently. Anyway a setup for it can be written. It uses UART and vs3emu.

So what runlevel and and interfaces you have available?
regh
Senior User
Posts: 39
Joined: Thu 2020-11-05 13:50

Re: Production programming using SPI Flash as program memory

Post by regh »

Thanks for the fast response Hannu.
I haven't come across the external flash prommer, is it mentioned in the handbook? Are there any links available that introduce this?
At present, the config file we have has runlevels [0] and [?] (I can't remember the numerical run level ? one corresponds to) set to run our software. We'll have a usb interface to store audio, although using a custom connector to handle this. I assume we'll also have to have a uart interface to send any serial commands for testing/programming the device in production.
It's been a while since I've used a vs1010 development board that didn't have my own software on it. What run level does the vs1010 chip run in by default (i.e. when it can't find a sys folder on either sd of flash memory)?
Hannu
Senior User
Posts: 158
Joined: Mon 2016-05-30 11:54

Re: Production programming using SPI Flash as program memory

Post by Hannu »

The programmer can be found from VSIDE project->prommer/flasher and selecting chip as VS1010.
The prommer code looks it was developed against VS1010B but quickly looking at it shouldn't be broken. I think it needs some testing against current VS1010 and writing some instructions how to make the master image and how to write it to device.

Devboard starts at runlevel 15. Runlevels 0 and 15 are normal player mode and after reset getting to the console is simply sending enter.

If the custom connector and debug serial port can be used, I would use those. It would test that VS1010 starts, UART SPI are connected and the connector works and has good contacts. Also programming time is faster.

if the USB has connector to be enabled by changing some GPIO state, it is also possible with poke command and changing the GPIOx_registers before commanding the reboot 4.

There is also one possibility more. If the USB can be accessed without GPIO activity, pull XHLD0, XWP0, and SCK0 down (MOSI0 should be pulled up) with smaller resistors (if pull-up is 10k, use 1k pull-down) and release reset or power the VS1010. If your production test jig support this action. That way the vs1010 will boot straight to SPI USB mass storage mode.
User avatar
Panu
VSDSP Expert
Posts: 2816
Joined: Tue 2010-06-22 13:43

Re: Production programming using SPI Flash as program memory

Post by Panu »

Boot runlevel is determined by pulling SPI0 pins weakly high or low at startup.

Image

viewtopic.php?t=2175
User avatar
Panu
VSDSP Expert
Posts: 2816
Joined: Tue 2010-06-22 13:43

Re: Production programming using SPI Flash as program memory

Post by Panu »

It only requires 3 pins to connect an SD card (SD_CLK, SD_CMD, SD_DAT0).

My suggestion is to put contact pads to the edge of the PCB for these signals, as well as GND and VHIGH and use jig pins to connect an SD card to these pads in a programming jig, to run the production prommer firmware from an external SD card. The PCB itself doesn't need an SD connector.

-Panu

PS. When you program the SPI flash contents, put a line such as D:UPDATE.DLX to the beginning of the CONFIG.TXT so that it tries to run UPDATE.DLX from an SD card before proceeding to the real firmware. This way you have the option of reprogramming the device later.
regh
Senior User
Posts: 39
Joined: Thu 2020-11-05 13:50

Re: Production programming using SPI Flash as program memory

Post by regh »

I just tried running a program from the SPI flash on the VS1010 devboard v1.4 and get the following error part way through the program

X:0 Corrupt (85fe) at 9c76, was still ok at 9c74, lr0=80f7.

I used the approach of booting in runlevel 4 then copying files over. The exact same files work fine when running from the sd card. Any ideas?
User avatar
Panu
VSDSP Expert
Posts: 2816
Joined: Tue 2010-06-22 13:43

Re: Production programming using SPI Flash as program memory

Post by Panu »

Hi!

The system timer interrupt runs once per millisecond. One of the things it does is check that address zero in X memory has the value zero. VSOS wants the first few words of X:memory to contain zeroes. This allows us to trap an early error from a few cases where there is an uninitialized object in the memory, such as writing to an unopened file, as well as detect writes through a null pointer (this has happened in your code) or calling a non-existing method.

In your case, something has written the value 0x85fe to address zero, and the interrupt handler has deteced this. It also shows that the core has been running code at address 0x9c76 when the timer interrupt occurred, that detected this. I can explore the VS1010 binaries and from there I can see that it has been running vs1010c0.coff::Uart0PutChar function.
uart0putchar.png
uart0putchar.png (100.01 KiB) Viewed 357 times
Unfortunately this doesn't really tell us anything, just that it was printing something when it detected the error.

Does the code have an unexpected file name reference to the D: disk (SD card) instead of S: disk (abstract system disk) that might break now when the code is not being run from the SD card?

Oh, also load and run the syscheckdlx program from viewtopic.php?f=15&t=2733&p=13931#p13931 to check that none of the firmware files in the flash are corrupted. Sometimes when using the runlevel 4 ROM, the last write in the RAM buffer is not correctly flushed to the SPI flash. Workaround is to run the USB mass storage from command line or from CONFIG.TXT, see viewtopic.php?t=2368

Once your programming work is complete, you can use the flshtool from viewtopic.php?f=15&t=2630 to deploy firmware and updates to your customers using the SD card. My solution is to put a D:UPDATE.DLX line to CONFIG.TXT in the flash, so the firmware tries to run update.dlx from the root of the sd card before continuing to run the actual firmware. This way if you insert and SD card with UPDATE.DLX in the root, you can make an SD card that rewrites the flash from a flash image in the SD card. (You can use any file name you want and it doesn't have to end in .dlx). Also you can put CONFIG.TXT in the SD card so it will run the updater also if the flash is empty. See page 173 of the VS1010 Handbook for a complete list of boot options, such as D:VSPLAYER.DLX...

-Panu
regh
Senior User
Posts: 39
Joined: Thu 2020-11-05 13:50

Re: Production programming using SPI Flash as program memory

Post by regh »

Hi Panu

Yes, the error occured whilst using printf.

I've uploaded code using ums function and it doesn't appear to fix things. Running syscheckdlx shows that everything is fine in the SYS folder on the device. I've used findstr on my source code to see if I can find anywhere that tries to look at the sd card (findstr /I "d:") but nothing has shown up.

The corruption error occurs after loading usbhost4. If I don't load it then I don't get the corruption error, but another problem occurs in that the next dlx that is meant to be called isn't run. So my project as a bootloader script that calls separate dlxs to do different functions (set up code, main application etc). After removing RunLib("UsbHost4", NULL) I no longer get the corruption error, but the dlx called the next time RunLib is used doesn't get entered (I have printf statements at the start of each program so I know where it is and these aren't occurring).
User avatar
Panu
VSDSP Expert
Posts: 2816
Joined: Tue 2010-06-22 13:43

Re: Production programming using SPI Flash as program memory

Post by Panu »

Hmm. Strange.

Does your code write to the S: disk (SPI flash now)? Using fwrite or something like that?
Post Reply