... revB Eval Board
...
EDIT2: 360 MHz fell over around 30 °C. 340 MHz made it to 65 °C. 330 MHz got to 80 °C. 320 MHz got about 100 °C.
So that is Dual-SPI loader, ES2 silicon, RevB PCB, and tests to something above 300MHz SysCLK and 150MHz SPI clock ? Wow.
At those speeds, PCB trace length / loading will matter.
Do you cross page boundaries at full speed, or do you pause on a boundary ?
Do you have any ISSI SPI RAMs, I wonder how much their 45MHz spec can overclock ?
I never saw any mention of memory pages in the Winbond documentation when reading up on the fast read commands. I had even forgotten about it as a possible concern ... looking now, the only place that page boundaries are mentioned is when erasing/writing the device.
Nope, don't have any SPI RAMs. Last time I coded anything for SPI, the year was 1995. A 68HC11 talking to one EEPROM for power down state store and a chain of 8x8 LED drivers. I got confused with either the SPI config or the EEPROM sequencing, and was on the clock, so decided to use the more fragile internal EEPROM instead. I devised a basic wear levelling, though probably didn't need that extra protection in the end because they never turned the equipment off anyway.
This Winbond part has a nice sequencing interface. I'm guessing that other brands don't always keep it this simple. The basic rule with the Winbond is all commands start with CS going low, and that always resets the data pins config back to simple SPI mode. The 8 bits of command is always issued as 1-bit serial. The command defines the bus width from then on until CS goes high.
You could say it doesn't have sticky interface modes.
PS: I found I could go completely gapless on the 2-bit data. The processing can keep up, just. After the read length is extracted from first four bytes, the clocking is one huge continuous stream of SPI clocks. The clocking smartpin is even commanded outside the processing loop.
'full-on continuous burst, right up to sysclock/2!
wrfast #0, #0 'start FIFO at beginning of hubRAM
shl pa, #4 'x16 clocks per longword
wypin pa, #spi_clk 'start clocking for the full length
.loop
call #read_byte4
movbyts pa, #%%0123 'want as little-endian
wflong pa
djnz .lcount, #.loop
outh #spi_cs
rdfast #0, #0 'flush the FIFO
PS: I found I could go completely gapless on the 2-bit data. The processing can keep up, just. After the read length is extracted from first four bytes, the clocking is one huge continuous stream of SPI clocks.
I never saw any mention of memory pages in the Winbond documentation when reading up on the fast read commands. I had even forgotten about it as a possible concern ... looking now, the only place that page boundaries are mentioned is when erasing/writing the device.
Ahh, I found it, - is mentioned in the LY68L6400 PSRAM data
says "144MHz max without crossing page boundary , and 84MHz max when burst commands cross page"
That's because it needs to load the next page, which takes a bit longer than a read of the next-byte from an already loaded buffer.
Maybe the FLASH have a similar issue - or maybe they do something different ? Seems fundamental a reload of buffer is needed somewhere ?
You could say it doesn't have sticky interface modes.
Ah! That's called Dual SPI interface mode. That's the distinction between the names Quad SPI vs QPI and Dual SPI vs DPI. Hmm, I doubt that's a rigid definition. Just one of those evolved naming conventions.
Seems fundamental a reload of buffer is needed somewhere ?
All it needs is a long enough buffering to keep shifting out the final bits of prior page while the new page gets selected. Eight 4-bit words would be heaps me thinks.
I still seem to need to flip switch to turn P59 pullup on in order to program flash.
Then, I need to turn that switch off for it to boot from flash.
And, if I want to reprogram RAM, I need to turn that switch back on...
Is anybody able to do like you can on P1 with eeprom and program both Flash and RAM and be able to boot from Flash without messing with pullups?
I still seem to need to flip switch to turn P59 pullup on in order to program flash.
Then, I need to turn that switch off for it to boot from flash.
And, if I want to reprogram RAM, I need to turn that switch back on...
Is anybody able to do like you can on P1 with eeprom and program both Flash and RAM and be able to boot from Flash without messing with pullups?
On my P2ES board I just have to flip the "FLASH" switch to the "on" position, with all the others (including P59 pullup/pulldown) in "off". I'm using the P2ES_flashloader program by ozpropdev and evanh, slightly modified by me (it's the version that comes with loadp2) and programming flash with:
I still seem to need to flip switch to turn P59 pullup on in order to program flash.
Then, I need to turn that switch off for it to boot from flash.
And, if I want to reprogram RAM, I need to turn that switch back on...
Is anybody able to do like you can on P1 with eeprom and program both Flash and RAM and be able to boot from Flash without messing with pullups?
I think that is set by the Boot decision process, in the DOCs it says this for example :
pull-up P61 : Serial window of 100ms, then SPI flash. If SPI flash fails then serial window of 60s.
That gives you a slowish path to flash boot, and allows serial load inside that 100ms window.
I think that covers RAM Pgm and Flash boot, and if you want Flash pgm, you need to load a flash-pgm stub first ?
This Winbond part has a nice sequencing interface. I'm guessing that other brands don't always keep it this simple. The basic rule with the Winbond is all commands start with CS going low, and that always resets the data pins config back to simple SPI mode. The 8 bits of command is always issued as 1-bit serial. The command defines the bus width from then on until CS goes high.
You could say it doesn't have sticky interface modes.
Does this mean the boot loader uses 2-bit modes and relies on the SPI flash chip to be a Winbond part?
Rayman> Is anybody able to do like you can on P1 with eeprom and program both Flash and RAM and be able to boot from Flash without messing with pullups?
I think that is set by the Boot decision process, in the DOCs it says this for example :
pull-up P61 : Serial window of 100ms, then SPI flash. If SPI flash fails then serial window of 60s.
That gives you a slowish path to flash boot, and allows serial load inside that 100ms window.
I think that covers RAM Pgm and Flash boot, and if you want Flash pgm, you need to load a flash-pgm stub first ?
So if I only have a pullup on P61 I should be able to RAM program, flash program and flash boot without changing jumpers, right?
I saw, the P2D2 has an additional 1M pulldown on P60. Whas is that good for?
Does this mean the boot loader uses 2-bit modes and relies on the SPI flash chip to be a Winbond part?
Pretty much yep, it's all I had to work with. It's easy enough to revert back to original simple 1-bit SPI that Oz wrote it as but I'll have a go at testing for faster modes with the slow mode as a fallback.
I saw, the P2D2 has an additional 1M pulldown on P60. Whas is that good for?
This simplifies SD card detection so that when no card is present I only need to check for a low rather than timing a float. Cards have an internal pullup on the CS line which can be used to detect the card.
>Does this mean the boot loader uses 2-bit modes and relies on the SPI flash chip to be a Winbond part?
Pretty much yep, it's all I had to work with. It's easy enough to revert back to original simple 1-bit SPI that Oz wrote it as but I'll have a go at testing for faster modes with the slow mode as a fallback.
Yes, that's true. It works with the Winbond flash and doesn't with a Macronics one. Generally, I think it's a bad idea to make the bootloader dependant on a particular chip manufacturer. If speed is important (I think for most smaller programs it's not) then there could be an option to enable fast mode (or more fancier with autodetecting the chip ID). But the default mode should be as "defensive" as possible supporting different ROM sizes and manufacturers.
Don't take this as complaint. I know how it is in life. You code some quick hack to make some paticular thing work and the next day everybody is using it as general purpose tool. You never know in advance...
It'll be interesting to find if the timings also need loosened - limiting to sysclock/4. I'm hoping not as it most likely is about the internal prop2 I/O rather than the SPI part. I hope you've got a spare board built so you can do testing of both EEPROMs for me.
I hope you've got a spare board built so you can do testing of both EEPROMs for me.
Hardware - no problem. I have two boards assembled, one with the Winbond flash, one with the Macronics. Software - eeerr, I'm still an absolute beginner. All I know is how to load a spin program into FlexGui, run it and see what happens. If this requires special compiler options or whatsoever you have to tell me step by step what to do.
I'll just be making new Loadp2's. FlexGUI probably has option for changing the loader command name, this way you can have multiple copies of loadp2 to try out. I've not used FlexGUI though, so not sure.
Alternative would be keep renaming the loadp2 to be tested so that FlexGUI will use that one.
Comments
At those speeds, PCB trace length / loading will matter.
Do you cross page boundaries at full speed, or do you pause on a boundary ?
Do you have any ISSI SPI RAMs, I wonder how much their 45MHz spec can overclock ?
I never saw any mention of memory pages in the Winbond documentation when reading up on the fast read commands. I had even forgotten about it as a possible concern ... looking now, the only place that page boundaries are mentioned is when erasing/writing the device.
Nope, don't have any SPI RAMs. Last time I coded anything for SPI, the year was 1995. A 68HC11 talking to one EEPROM for power down state store and a chain of 8x8 LED drivers. I got confused with either the SPI config or the EEPROM sequencing, and was on the clock, so decided to use the more fragile internal EEPROM instead. I devised a basic wear levelling, though probably didn't need that extra protection in the end because they never turned the equipment off anyway.
You could say it doesn't have sticky interface modes.
Ahh, I found it, - is mentioned in the LY68L6400 PSRAM data
says "144MHz max without crossing page boundary , and 84MHz max when burst commands cross page"
That's because it needs to load the next page, which takes a bit longer than a read of the next-byte from an already loaded buffer.
Maybe the FLASH have a similar issue - or maybe they do something different ? Seems fundamental a reload of buffer is needed somewhere ?
Then, I need to turn that switch off for it to boot from flash.
And, if I want to reprogram RAM, I need to turn that switch back on...
Is anybody able to do like you can on P1 with eeprom and program both Flash and RAM and be able to boot from Flash without messing with pullups?
Think that makes a difference?
On my P2ES board I just have to flip the "FLASH" switch to the "on" position, with all the others (including P59 pullup/pulldown) in "off". I'm using the P2ES_flashloader program by ozpropdev and evanh, slightly modified by me (it's the version that comes with loadp2) and programming flash with:
Pnut F11 command works fine with "FLASH" on and loads RAM Ok.
I think that is set by the Boot decision process, in the DOCs it says this for example :
pull-up P61 : Serial window of 100ms, then SPI flash. If SPI flash fails then serial window of 60s.
That gives you a slowish path to flash boot, and allows serial load inside that 100ms window.
I think that covers RAM Pgm and Flash boot, and if you want Flash pgm, you need to load a flash-pgm stub first ?
I'll transition to the new one...
Does this mean the boot loader uses 2-bit modes and relies on the SPI flash chip to be a Winbond part?
So if I only have a pullup on P61 I should be able to RAM program, flash program and flash boot without changing jumpers, right?
I saw, the P2D2 has an additional 1M pulldown on P60. Whas is that good for?
Yes, that's right. No jumpers needed when just using flash. This is the best way for me.
This simplifies SD card detection so that when no card is present I only need to check for a low rather than timing a float. Cards have an internal pullup on the CS line which can be used to detect the card.
Yes, that's true. It works with the Winbond flash and doesn't with a Macronics one. Generally, I think it's a bad idea to make the bootloader dependant on a particular chip manufacturer. If speed is important (I think for most smaller programs it's not) then there could be an option to enable fast mode (or more fancier with autodetecting the chip ID). But the default mode should be as "defensive" as possible supporting different ROM sizes and manufacturers.
Don't take this as complaint. I know how it is in life. You code some quick hack to make some paticular thing work and the next day everybody is using it as general purpose tool. You never know in advance...
Hardware - no problem. I have two boards assembled, one with the Winbond flash, one with the Macronics. Software - eeerr, I'm still an absolute beginner. All I know is how to load a spin program into FlexGui, run it and see what happens. If this requires special compiler options or whatsoever you have to tell me step by step what to do.
Alternative would be keep renaming the loadp2 to be tested so that FlexGUI will use that one.