VS1000b, SPI LOAD

Writing software that controls the system and peripherals such as displays, SD cards, Buttons, LEDs, Serial Ports etc.
HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

VS1000b, SPI LOAD

Post by HeLiO » Thu 2013-01-31 11:22

Hi, VLSI
TEAM!

I have used the multi load techniques with your chip VS1000b.
It uses SPI FlASH to load new "portion" of code data into VS1000b RAM by following sample code:

Code: Select all

short newPartAddr = (short)FIRMWARE_PART_PLAYER;
SpiLoad(newPartAddr+4, 1/*24-bit address*/);
But , taking into account the size of SPI FALSH you claim to be supported (up to 24 bit addressing ~ 16 mbit), and comments /*24 bit address*/ i cant yet figure out why fucntion declared in vs1000.h:

Code: Select all

/*
  Boot-related functions.
 */
/* SpiBoot() and SpiLoad() do not return!
   m24 = 0 for 16-bit SPI EEPROM address.
 */
void SpiBoot(register __a0 short clkConf, register __i2 short addr,
	     register __i0 short m24);
/* SpiBoot(SPI_CC_CLKDIV*7 | SPI_CC_CLKOPOL, 0, 0); */
void SpiLoad(register __i2 short startAddr, register __i0 short m24);
void SpiDelay(register __a0 u_int16 wait);
auto u_int16 SpiSendReceive(register __a0 u_int16 data);
have short input address type ??
How can iwrite to address with offset of 70 000 and more than ?

Thank you for advance

Peter

User avatar
Panu
VLSI Staff
Posts: 2798
Joined: Tue 2010-06-22 13:43

Re: VS1000b, SPI LOAD

Post by Panu » Thu 2013-01-31 12:08

Hi!

Often the 24-bit support just pads the 16-bit address with an extra zero. ("if (24 bit mode) then spiput(0)".) I think that may be the case here.
i cant yet figure out why fucntion declared in vs1000.h (void SpiLoad(register __i2 short startAddr, register __i0 short m24);) have short input address type ??
The reason ( :o ) is that for IC production test reasons, the bootloader must also work in a chip that has a broken RAM. That's why the bootloader is written in assembler, never reads from RAM (only uses registers) and is kept as simple as possible. The address is 16 bits only because that's more than enough for the bootloader. For other uses, you'll need to load functions that can use the higher addresses in the flash. Many of our example files contain such functions.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

Re: VS1000b, SPI LOAD

Post by HeLiO » Thu 2013-01-31 12:30

Ok the reason is clear now, so but what about your proposal - it is not all clear for me yes..
ABout adding PADding 0 .
Can you clear it out ?

Thanks

User avatar
Henrik
VLSI Staff
Posts: 1199
Joined: Tue 2010-06-22 14:10

Re: VS1000b, SPI LOAD

Post by Henrik » Fri 2013-02-01 9:59

It means that this version of the bootloader can boot from either 16-bit or 24-bit memory (they are accessed in a different way), but only from the first 64 KiB of address space. Then the code loaded from the memory can have another loader that can do full 24-bit addressses.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

Re: VS1000b, SPI LOAD

Post by HeLiO » Fri 2013-02-01 10:41

Henrik wrote:It means that this version of the bootloader can boot from either 16-bit or 24-bit memory (they are accessed in a different way), but only from the first 64 KiB of address space. Then the code loaded from the memory can have another loader that can do full 24-bit addressses.

Kind regards,
- Henrik
That sounds awful ,caue we are porting Project > 256 KiB form NAND multi load based project consisting
about 16 modules to SPI FLASH.
We have reached 64 KiB limit, an d on ly on this point i mentioned (bad for me) this restriction..

Is it exhaust of SPI LOAD capacity as a way of sectioning Firmware into small parts ,or can you offer some way to overcome this problem ?


Thank you very much

User avatar
Panu
VLSI Staff
Posts: 2798
Joined: Tue 2010-06-22 13:43

Re: VS1000b, SPI LOAD

Post by Panu » Fri 2013-02-01 11:31

Woops, we never thought that VS1000 would need to run such a large code :shock:

Let us think for a while for the smallest implementation of SpiLoad that we can come up with. You're using VS1000b, right? Or also VS1000d?

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

Re: VS1000b, SPI LOAD

Post by HeLiO » Fri 2013-02-01 12:04

Panu wrote:Woops, we never thought that VS1000 would need to run such a large code :shock:

Let us think for a while for the smallest implementation of SpiLoad that we can come up with. You're using VS1000b, right? Or also VS1000d?

-Panu

VS1000b only.
Boot: from SPI FLASH
Content: SD/SDHC card

HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

Re: VS1000b, SPI LOAD

Post by HeLiO » Wed 2013-02-06 13:42

Any further ideas... .?

HeLiO
Senior User
Posts: 94
Joined: Thu 2011-04-14 12:47

Re: VS1000b, SPI LOAD

Post by HeLiO » Thu 2013-02-14 11:19

Thread is still VERY actual.
We are stamping on one place cause of that restriction, could you make some comments on this issue please?

Tnanks

User avatar
Panu
VLSI Staff
Posts: 2798
Joined: Tue 2010-06-22 13:43

Re: VS1000b, SPI LOAD

Post by Panu » Thu 2013-02-14 13:10

Hi,
I just realized that without taking special precautions, you can't run SpiLoad from RAM because (if you use multiload) you'll probably be writing over that RAM so it's sure to crash. If you're very careful, you could write SpiLoad in assembly language to force it to a location somewhere in IRAM where you'd never link any other code... :oops:

If you were using overlays, I would be able to help but now I must get Pasi to look at this.

how much over the 64K are you exactly?

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

Post Reply