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.
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.
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.
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. 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! 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!
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.
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.
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 ...
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.
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.
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.
In my original flash loader the code was stored at $1_0000.
BTW isn't the MX25V8035FM a 2.5V part?
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.
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.
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.
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!
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.
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.
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.
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.
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:
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.
... 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.
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? I don't have a P2ES or P2D2. This is a custom board.
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.
Err, which DIP switch? I don't have a P2ES or P2D2. This is a custom board.
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 ...
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.
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.
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.
Comments
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.
Cool. When I said "should definitely be fixed soon" I didn't mean that soon.
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!
Sorry, I know it's not your fault and you don't get payed for it. Thanks to everyone for helping me!
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.
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 ...
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.
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.
In my original flash loader the code was stored at $1_0000.
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.
I left the 'F' off the part number which led me to the 2.5V only part. Oops!
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.
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.
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.
Err, which DIP switch?
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.
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.
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.
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 ...
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.
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
EDIT: Changed to 230400 baud