Shop OBEX P1 Docs P2 Docs Learn Events
How to start - Page 2 — Parallax Forums

How to start

2

Comments

  • evanhevanh Posts: 15,126
    I've done a rough cut'n'paste routine for verify of the first 1kB stage1 loader and it seems to check out good. Not well tested yet ... and off to bed now.
    verify_stage1	mov	pages,#4
    		mov	addr,#0
    		loc	ptra,#@stage1
    .loop2
    		mov	byte_count,#256
    		outl	#spi_cs
    		mov	pa,#read_data
    		call	#send_byte
    		call	#send_addr24
    .loop
    		mov	val,#0
    		call	#read_byte
    		rdbyte	pa,ptra
    		cmp	pa,val		wz
    	if_z	add	ptra,#1
    	if_z	djnz	byte_count,#.loop
    
    		outh	#spi_cs
    	if_z	call	#busy
    	if_z	add	addr,#256
    	if_z	djnz	pages,#.loop2
    		ret
    
  • Ok, TAQOZ prints this:
    TAQOZ# .SF --- $C223_14C2 $0000_0000_$0000_0000 ok
    TAQOZ# 0 $40 SF DUMP ---
    00000: 59 7A 64 FD  58 78 64 FD  58 76 64 FD  00 72 60 FD     'Yzd.Xxd.Xvd..r`.'
    00010: 1F 74 60 FD  03 72 44 F5  00 72 60 FD  80 00 00 FF     '.t`..rD..r`.....'
    00020: 00 EE 07 F6  48 7A 64 FD  31 76 4C FB  F7 ED F3 F8     '....Hzd.1vL.....'
    00030: BC 00 B0 FD  F7 ED EB F8  B4 00 B0 FD  F7 ED E3 F8     '................' ok
    TAQOZ# $0400 $0440 SF DUMP ---
    00400: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00410: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00420: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00430: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    00440: FF FF FF FF  FF FF FF FF  FF FF FF FF  FF FF FF FF     '................'
    

    So the flash is not completely empty but the actual code is missing. The first page starting at $0 is also different from the contents of the binary file. I have too little knowledge to tell what's actually happening here. The flash ID also differs but that's to be expected as manufacturer and size is diffferent.

    I have ordered a W25Q128 to check if it's a compatibility issue. Should arrive tomorrow.
  • evanhevanh Posts: 15,126
    In Loadp2, the first 1kB of the EEPROM is set aside for the boot loader. Your binary gets placed at 4 kB in hubRAM during the programming and it looks like that is mirrored into the EEPROM, so expect to find your code located from EEPROM byte address $1000 onward.

  • evanh wrote: »
    I've done a rough cut'n'paste routine for verify of the first 1kB stage1 loader and it seems to check out good. Not well tested yet ... and off to bed now.

    Cool. When I said "should definitely be fixed soon" I didn't mean that soon. :wink: Don't hurry.

    I just had this idea: For my servo controller project I have to use the EEPROM for storing motor and PID parameters, anyway. I don't need a real file system. Just copying an array of variables to EEPROM and back should do. If I test that and use the same SPI driver I'll probably find out why it doesn't work with my type of EEPROM. It doesn't really matter for now. If it only works with the winbond chip it's OK for prototyping. But as I plan to make volume production some day I'd like to have a ROM as small as possible. The W25Q128 is around $1.50, the MX25V8035 costs only $0.35.

    Where can I find the full source code of the P2 flashloader? (mainly the send_byte and read_byte functions you call in the quoted code above) I've looked at dave hein's github page but haven't found them there. Peter's TAQOZ SPI driver is very sparse.

    I feel so clumsy and unskilled! :neutral: When I started with the P1 I was able to learn everything within a few days. There were good tutorials and all documentation you need. With the P2 everything is hard. I have to dig through heaps of forum discussions to find out how things work. I hope it doesn't have to do with the fact that I'm also 10 years older now.

    Sorry, I know it's not your fault and you don't get payed for it. Thanks to everyone for helping me!

  • evanhevanh Posts: 15,126
    No, it's because the prop1 was developed more traditionally as incognito. It was a released product from day one. The prop2 is still in development, the docs and the product. Also, the open assistance and suggestions means Chip has bitten off a lot more this time around. As some have complained a little, the prop2 has a few kitchen sinks included.

    The up to date sources are now with Eric. Here's the location of the flashloader source - https://github.com/totalspectrum/loadp2/tree/master/board

    Did you check for your program stored in the EEPROM at 4 kB? I'm getting the feeling it is programmed fine but the bootloader placed in first 1 kB is at fault. I rewrote stage1 bootloader for speed and I did tune carefully for sysclock/2 in the Winbond part so it doesn't surprise me a different brand fails. Maybe a more robust timing arrangement is desirable instead - especially given it's not even operating that fast by default anyway.
  • evanhevanh Posts: 15,126
    edited 2020-01-10 11:02
    Oh, actually, reading the datasheet for the MX258035, it looks like the dualSPI fast read mode, $3B, I've used is not supported. The MX uses mode $BB instead ...

    EDIT: Right, yeah, that's the difference between DPI vs dualSPI. The MX chip supports DPI and QPI but not dualSPI and quadSPI. And of course the Winbond chip is the other way around. Huh, oops, the Winbond chip does support DPI/QPI as well ...
  • evanhevanh Posts: 15,126
    Hmm, not looking great for universal detection of supported modes. Winbond documents a $5A command "Read SFDP Register" for identifying the command set of the part, which apparently was formalised into JEDEC in 2010, but that one is not present in the MX chip. :(

    There's a few options, like if that command is not responsive then fall back to basic SPI read data, $03, or just try each fast read mode in turn and again try to identify responsiveness.

    At the moment, with the MX chip, it probably just reads continuous zeros then resets.

  • evanh wrote: »
    Did you check for your program stored in the EEPROM at 4 kB? I'm getting the feeling it is programmed fine but the bootloader placed in first 1 kB is at fault. I rewrote stage1 bootloader for speed and I did tune carefully for sysclock/2 in the Winbond part so it doesn't surprise me a different brand fails.

    Yes, I just have received the W25Q128, soldered it in and it now worked immediately. However, if I check the flash contents at $400 or $1000 it is still all empty. I don't understand it but at least it works, now. :smile:
  • ManAtWork wrote: »
    Yes, I just have received the W25Q128, soldered it in and it now worked immediately. However, if I check the flash contents at $400 or $1000 it is still all empty. I don't understand it but at least it works, now. :smile:

    In my original flash loader the code was stored at $1_0000.
    BTW isn't the MX25V8035FM a 2.5V part?

  • evanhevanh Posts: 15,126
    ozpropdev wrote: »
    In my original flash loader the code was stored at $1_0000.
    Bugger, missed it, I see it now. Yep, that's still the code address in the EEPROM.

  • evanhevanh Posts: 15,126
    Sorry, I'm not operating on all cylinders at the moment. Didn't get a lot of sleep due to leaking blood from a tooth extraction. Hopefully, tomorrow I'll be able to focus.
  • ozpropdev wrote: »
    BTW isn't the MX25V8035FM a 2.5V part?

    It's rated 2.3 to 3.6V. And another reason why I'd prefer this: it's smaller than the Windond. It uses a standard SO-8 instead of a wide body. So I could use a standard feeder on the P&P machine.

  • ManAtWork wrote: »
    ozpropdev wrote: »
    BTW isn't the MX25V8035FM a 2.5V part?

    It's rated 2.3 to 3.6V. And another reason why I'd prefer this: it's smaller than the Windond. It uses a standard SO-8 instead of a wide body. So I could use a standard feeder on the P&P machine.


    But the MX part is only 8Mbit whereas the Winbond part we use is 128Mbit or 16MB but I ended up using WSON8 that fits nicely plus it has a very low profile.
    I have lots of the older 8Mbit WInbond parts and they are standard 150mil wide SO-8 just like the MX parts.

    The lower voltage is of no benefit since the P2 I/O needs to run at 3.3V.
  • ManAtWork wrote: »
    ozpropdev wrote: »
    BTW isn't the MX25V8035FM a 2.5V part?

    It's rated 2.3 to 3.6V. And another reason why I'd prefer this: it's smaller than the Windond. It uses a standard SO-8 instead of a wide body. So I could use a standard feeder on the P&P machine.
    Ah yes.
    I left the 'F' off the part number which led me to the 2.5V only part. Oops! :blush:

  • I haven't had much time to tinker with my P2. So far I got it to blink some LED's and made it print out "Hello Bob". The Flex GUI and examples seem to work.
  • evanh wrote: »
    Hmm, not looking great for universal detection of supported modes. Winbond documents a $5A command "Read SFDP Register" for identifying the command set of the part, which apparently was formalised into JEDEC in 2010, but that one is not present in the MX chip. :(

    I think, the easiest and safest way to handle this is to leave the choice up to the user. The default should be using only standard (slow) SPI commands. If somebody want's to try out the faster (dual SPI) mode he can add an option in the command line.

  • evanhevanh Posts: 15,126
    I just got to get back into the zone. I'm still keen. It turns out the testing of each case is going to require a lot of smartpin mode switching and to not bloat the code too much I'm going to have to rewrite most of the boot loader.

  • It'd be perfectly reasonable to have two seperate programs, a dual SPI one and a regular SPI one. The user could select which one to use based on the board/flash that they have.

  • evanhevanh Posts: 15,126
    edited 2020-01-14 11:19
    Okay, I've replaced all the bit bashing in the stage1 boot loader with smartpin managed handling. It's still a fixed function blind setup with no testing of fast read modes as yet and these binaries are all the same except for the SPI clock/data rate. I've changed to DPI mode instead of dualSPI, so fingers crossed you'll see good results.

    ManAtWork,
    I'd like you to try each one of these on both of your boards. Start with the 20 MHz one and work up to the 100 MHz one. They indicate success as follows:
    20 MHz and 80 MHz: LED56 and LED57 flash in unison.
    40 MHz and 100 MHz: LED56 and LED57 alternate.

    As for downloading them, I was wrong about it being a Loadp2 replacements. You use Loadp2 to download these, eg: loadp2 -v -t P2ES_flashloader-20MHz.binary

    I'm not sure if FlexGUI will directly be very helpful. I expect you'll need to find where it has stashed loadp2 and use that.

    PS: Don't forget, turn on the FLASH dip switch. :)
  • loadp2 can also load data at other parts of memory (i.e. it can load the flashloader program, and then after that load some data into HUB). FlexGUI uses that to do the flash programming. I modified your (@evanh's) flash loader to always read the length from $1000 and the data from $1004, and then use:
    loadp2 -v -b230400 -t @0=P2ES_flashloader.bin,@1000+file.binary
    
    to flash "file.binary"; the @1000+ notation means to put the file length followed by file data at $1000, whereas @0= means to just put the file data there.

    The next version of FlexGUI will change $1000 to $8000 (to give the flash programming code 32K to work in; the SPI flash doesn't need that much, but SD card with FAT does) and will have a menu to allow you to choose which program to use for flash programming. The code for all of that is in github now.
  • evanhevanh Posts: 15,126
    ersmith wrote: »
    ... to flash "file.binary"; the @1000+ notation means to put the file length followed by file data at $1000, whereas @0= means to just put the file data there.
    Ah, I did wonder how the "size" location was handled.

  • evanh wrote: »
    I'd like you to try each one of these on both of your boards. Start with the 20 MHz one and work up to the 100 MHz one. They indicate success as follows:
    20 MHz and 80 MHz: LED56 and LED57 flash in unison.
    40 MHz and 100 MHz: LED56 and LED57 alternate.

    As for downloading them, I was wrong about it being a Loadp2 replacements. You use Loadp2 to download these, eg: loadp2 -v -t P2ES_flashloader-20MHz.binary

    PS: Don't forget, turn on the FLASH dip switch. :)

    Err, which DIP switch? :neutral: I don't have a P2ES or P2D2. This is a custom board. :wink:
    I also don't have LEDs on every pin. Fortunatelly, P57 is also an output on my board. I can see a toggelng voltage if I check with the multimeter.
    trying \\.\COM3...
    P2 version G found on serial port \\.\COM3
    Setting load mode to CHIP
    Setting clock_mode to 12427f8
    Loading fast loader for chip...
    Sending header
    Loading C:/Program Files (x86)/Parallax Inc/FlexGui/bin/P2ES_flashloader-20MHz.b
    inary - 4128 bytes
    chksum: c6 OK
    ( Entering terminal mode.  Press Ctrl-] to exit. )
     Ö↑☼µåf0▲3 ↑☼3xf...
    
    It outputs garbade characters at the terminal (wrong baud rate/frequency) but at least the LED (P57) is toggeling so I think loading works for 20MHz and the winbond flash. I'll check the other combinations later.

  • All versions from 20 to 100MHz work on the board with the Winbond flash. None of them work with the other board with the Macronix flash.

    I used the "run binary" command of FlexGui with your P2ES_flashloader-XXX.binary" files as argument. So it should have used the original loadp2.exe that comes with FlexGui to download the binary. I also verified that the pins 58 to 63 and the crystal work on both boards. If I run my blink program from RAM it works. TAQOZ displays some contents starting from $0000 so at least the flah memory gets written.
  • evanhevanh Posts: 15,126
    ManAtWork wrote: »
    Err, which DIP switch? :neutral: I don't have a P2ES or P2D2. This is a custom board. :wink:
    I also don't have LEDs on every pin. Fortunatelly, P57 is also an output on my board. I can see a toggelng voltage if I check with the multimeter.
    Doh! It's funny what gets assumed without a thought, even when it's obviously not true.
    It outputs garbade characters at the terminal (wrong baud rate/frequency) ...
    Ah, right, I think FlexGUI defaults to 230400 user baud, I'll use that for the next round. Thanks for the results, clearly still need to establish what will work for the MX chip ...

  • evanhevanh Posts: 15,126
    Oh, please use TAQOZ to read the MX flash chip at address $10000 (64 kB). We need to establish the programming is working and that only the booting is the issue.

  • TAQOZ# $10000 $40 sf dump ---
    0001_0000: 1C 00 00 00  59 70 64 FD  59 72 64 FD  00 08 DC FC     '....Ypd.Yrd..
    ...'
    0001_0010: 4F 70 64 FD  4F 72 64 FD  AF 2F 80 FF  1F 20 64 FD     'Opd.Ord../...
     d.'
    0001_0020: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '.............
    ...'
    0001_0030: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '.............
    ...' ok
    TAQOZ#
    
    I hope this is telling you something useful.
  • evanhevanh Posts: 15,126
    edited 2020-01-16 12:27
    Yep, perfect match. Yay for the Taqoz! :) Here's the assembled listing for the binary file:
    01000                 | size		long	@code_end - @code
    01000     1C 00 00 00 
    01004                 | 
    01004                 | code
    01004                 | 
    01004                 | 'example code indicating programming suceeded
    01004                 | 
    01004     59 70 64 FD | 		drvh	#56			'LED56 off
    01008     59 72 64 FD | 		drvh	#57			'LED57 off
    0100c                 | 
    0100c     00 08 DC FC | 		rep	@.floop, #0		'loop forever toggling the LEDs
    01010     4F 70 64 FD | 		outnot	#56
    01014     4F 72 64 FD | 		outnot	#57
    01018     AF 2F 80 FF 
    0101c     1F 20 64 FD | 		waitx	##(25_000_000/4)
    01020                 | .floop
    

    Now I just need another night sleep. Went through a whole pack of cheap paracetamol with an aching jaw only to work out it was Smile quality after changing back to a name brand. Maybe I shouldn't be but I'm actually surprised.

  • evanhevanh Posts: 15,126
    edited 2020-01-20 12:04
    Okay ManAtWork,
    Sorry for the delays, and there's more to come too.

    Got another test put together. This one is running very slowly but testing the edge timings. I'll be wanting the terminal output for the MX chip in particular, thanks.

    PS: This is what I get with the Winbond chip
      DPI   Dual   Fast   SPI
    --------------------------
     Pass   Pass   Pass   Pass  
     Pass   Pass   Pass   Pass  
     Fail   Fail   Fail   Fail  
     Pass   Pass   Pass   Pass  
     Pass   Pass   Pass   Pass  
     Pass   Pass   Pass   Pass  
     Pass   Pass   Pass   Pass  
     Fail   Fail   Fail   Fail  
    

    EDIT: Changed to 230400 baud
  • With the Winbond chip I get the same output. However, the board with the Macronix flash seems to crash before it can perform any of the tests.
    P2-ES Flash Programmer
    Erasing flash...
    Programming...
    Done
    
    It hangs after "Done".
  • evanhevanh Posts: 15,126
    Huh, that's weird. It prints the title line before any tests even start.
Sign In or Register to comment.