Prop2 Flash loader

13»

Comments

  • jmgjmg Posts: 14,224
    evanh wrote: »
    ... 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 ?
  • evanhevanh Posts: 8,749
    edited 2019-10-31 - 23:54:06
    All correct.

    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.
  • evanhevanh Posts: 8,749
    edited 2019-11-01 - 00:18:11
    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
    
  • jmgjmg Posts: 14,224
    edited 2019-11-01 - 02:02:35
    evanh wrote: »
    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.
    That's impressive :)


    evanh wrote: »
    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 ?


  • evanh wrote: »
    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.

  • evanhevanh Posts: 8,749
    edited 2019-11-01 - 04:54:05
    jmg wrote: »
    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?
  • Are you usng Pnut or Flexgui?
  • Fastspin/Flexgui
    Think that makes a difference?
  • Rayman wrote: »
    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:
    loadp2 -b230400 @0=board/P2ES_flashloader.bin,@1000+myprogram.binary
    
  • No P59 switches needed, just "FLASH".
    Pnut F11 command works fine with "FLASH" on and loads RAM Ok.
  • jmgjmg Posts: 14,224
    Rayman wrote: »
    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 ?
  • ok, I'm sure I have an old loadp2...
    I'll transition to the new one...
  • Ya, it was probably less than a month ago that we fixed exactly this issue in loadp2.
  • evanh wrote: »
    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?
    jmg wrote: »
    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?
  • ManAtWork wrote: »
    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.

  • ManAtWork wrote: »
    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?

    Yes, that's right. No jumpers needed when just using flash. This is the best way for me.
  • ManAtWork wrote: »
    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.

  • evanh wrote: »
    >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...
  • evanhevanh Posts: 8,749
    edited 2020-01-10 - 21:46:06
    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.

  • evanh wrote: »
    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. :blush:
  • 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.

Sign In or Register to comment.