Great! Sync is effectively a "minus 0.5" for delay, so 12 async is probably the sweetest spot.
If it runs stable for an elongated period, you've done a good job with the board design.
I can also send you the NeoGeo files, if you want. That's an extra 10 MHz or so of clock speed and also like an order of magnitude more memory activity.
Runs stable for now. I will leave it for a while as it is with no heatsink.
Sure, send whatever else that needs checking. I am also interested to see how it goes
Well, here's the thing. This one's hardcoded to run the sengoku2 romset, which I'll direct message you because copyright is a meanie. Might need a different memory config due to different clock, but probably not.
@knivd said:
P2-Stamp goes strong! D13 async seems to be the better option here. Steady 62C degrees on the chip with no heatsink.
D14 sync might work also.
PS: No guarantee of course. The warmer the chip gets the tighter the timing becomes. And upping the sysclock frequency also shifts the sweet spot into tighter territory.
Okay, going for about 12 hours now. That is reasonably conclusive. P2 measuring 63 degrees on the surface.
I am pleased by the result. This is not a particularly entry-level module, designed for serious applications where stability is an important factor, and I would have hated if it had failed right at the start.
I think I still might have made some mistake, though...
Fortunately, doesn't seem to be a critical one. The BOOT0 signal is supposed to control the pull-up on P61, which it currently doesn't. Essentially, it looks like I need to connect BOOT0 to P61 (or have an external pull-up on P61) in the current configuration in order to get the P2 start with whatever is in the flash memory. This makes U1 redundant. I will play a bit with it and make corrections in the schematic if necessary.
I am really stuck here, which is obviously with me doing something wrong. No luck with programming the flash. Program (simple blinky) loads and executes, but no more after restart.
Tried with Flexprop, loadp2:
Tried also with the Parallax Tool. On F11 it just gives the message about successful compilation and load.
I checked the datasheet hundred times. Probably a very stupid question, but... how can I get P2 to execute from flash after a reset?
loadp2 on it's own can't program flash. Need to use some weird command line to pre-pend the flash loader onto the application. Propeller Tool should work though.
Also, flash boot might not work with an SD card inserted.
SD will interfere when there is a valid boot file. Otherwise no problem, afaik.
Making an EEPROM image using loadp2 requires using the P2ES_flashloader.spin2 installer program. I think there is multiple ways to append files in either source form or binaries, but basically the target code is appended to the end of P2ES_flashloader.spin2 and the size parameter is set correctly then it should write itself to EEPROM when loaded into the Prop2.
NOTE: My smartpin addition to it was a little over zealous with the unnecessary use of DualSPI interface mode. I made it faster than I should have on something that really needed widest compatibility. There is something like six different modes out there. Needless to say there are some EEPROMs that don't support DualSPI. Although tests show, I think, most failed boots are a compatibility problem in the ROM's EEPROM probing routine failing to elicit a response.
@knivd said:
Yes, it is puzzling. The Propeller Tool says it is done, but it works only until reset. Is there any way at all to verify the content of the flash?
ManAtWork had a conversation running with a list of tested EEPROMs. I'm guessing it was in his KISS board topic ...
@knivd said:
Okay, going for about 12 hours now. That is reasonably conclusive. P2 measuring 63 degrees on the surface.
I am pleased by the result. This is not a particularly entry-level module, designed for serious applications where stability is an important factor, and I would have hated if it had failed right at the start.
This is a great result. Glad your HyperRAM is working well @knivd.
Maybe you have V2 HyperRAM if your default latency is different. That different default setup is not yet put into my drivers although I think there was an API you can call to change it or a file change might be required. Perhaps if it is initialisation related it needed special attention beforehand for it to work, unfortunately it's been quite a while since I even looked at this stuff and have not had V2 HyperRAM to try out in person to date.
Maybe you have V2 HyperRAM if your default latency is different. That different default setup is not yet put into my drivers although I think there was an API you can call to change it or a file change might be required. Perhaps if it is initialisation related it needed special attention beforehand for it to work, unfortunately it's been quite a while since I even looked at this stuff and have not had V2 HyperRAM to try out in person to date.
Yes, I admit that during the design phase I selected the components on the basis of hardware suitability rather than pre-existing support. My hope is that if the module is proven good for high-end real world applications, that support will gradually appear (including input from myself with me improving on the software side with the time).
It is not without problems, but as you know hardware almost never is. Fortunately, so far those problems are all solvable - software adjustments for the HyperRAM, probably the same for the flash, or in the worst case scenario I can change to something else in the same package - W25Q512JVBIQ for example, which is from the already verified Winbond's W25Q series. All will come in place with time.
@rogloh said:
Maybe you have V2 HyperRAM if your default latency is different. That different default setup is not yet put into my drivers although I think there was an API you can call to change it or a file change might be required. Perhaps if it is initialisation related it needed special attention beforehand for it to work, unfortunately it's been quite a while since I even looked at this stuff and have not had V2 HyperRAM to try out in person to date.
I don't think this is V2 specific - the ISSI V1 part has the same config register, the newer Winbond part just defaults to 7 instead of 6 (presumably to match the higher clock speeds it supports).
To optimise my testing process I made a simple P2-STAMP breakout board.
It is basically just headers out of the module, and the headers can be installed in several different ways - horizontal, vertical, or in two distanced lines for prototyping board compatibility.
I will put the gerbers of this one in the same github repo as the module itself.
Have been playing a bit with TAQOZ, and it turns out it can write and read from the module's flash without any issues. But not FlexProp can't, despite issuing a message for successful operation
I then took one of these W25Q512JVBIQ, and manually replaced it on one module. Same result - TAQOZ happy and successful, FlexProp also happy, but not successful.
Starting to think that I am not doing something right... Is there any hidden secrets to program a .spin2 file into the flash memory, and then make it run on power up?
Some flash chips need a pulldown on P58. The bootloader uses pullups and pulldowns on P59-61 to select the boot mode.
You don't want to program a .spin2 file, you want to program a .binary file. I make that mistake occasionally when using loadp2 from the command line. If you're using flexprop it's unlikely this is the issue.
I'd make a breakout similar to, and compatible with, the Eval Boards. Besides the connector compatibility, you get much better high-speed signal behaviour then. And it'll serve as a great replacement since Parallax seem to be discontinuing the reference Eval Board itself.
In fact I still think Parallax should pick up the Stamp as a stocked line in their shop.
Comments
Great! Sync is effectively a "minus 0.5" for delay, so 12 async is probably the sweetest spot.
If it runs stable for an elongated period, you've done a good job with the board design.
I can also send you the NeoGeo files, if you want. That's an extra 10 MHz or so of clock speed and also like an order of magnitude more memory activity.
Runs stable for now. I will leave it for a while as it is with no heatsink.
Sure, send whatever else that needs checking. I am also interested to see how it goes
Well, here's the thing. This one's hardcoded to run the
sengoku2romset, which I'll direct message you because copyright is a meanie. Might need a different memory config due to different clock, but probably not.P2-Stamp goes strong! D13 async seems to be the better option here. Steady 62C degrees on the chip with no heatsink.
You have a quality design on your hands then!
Don't think we have cookies in the house right now though, so no cookie JPEG.
I am going to leave running overnight and will see how it does tomorrow...
Congrats on passing this test! None of my boards can
D14 sync might work also.
PS: No guarantee of course. The warmer the chip gets the tighter the timing becomes. And upping the sysclock frequency also shifts the sweet spot into tighter territory.
Okay, going for about 12 hours now. That is reasonably conclusive. P2 measuring 63 degrees on the surface.
I am pleased by the result. This is not a particularly entry-level module, designed for serious applications where stability is an important factor, and I would have hated if it had failed right at the start.
Knew it would. It just looked too good a design.
I think I still might have made some mistake, though...
Fortunately, doesn't seem to be a critical one. The BOOT0 signal is supposed to control the pull-up on P61, which it currently doesn't. Essentially, it looks like I need to connect BOOT0 to P61 (or have an external pull-up on P61) in the current configuration in order to get the P2 start with whatever is in the flash memory. This makes U1 redundant. I will play a bit with it and make corrections in the schematic if necessary.
I am really stuck here, which is obviously with me doing something wrong. No luck with programming the flash. Program (simple blinky) loads and executes, but no more after restart.
Tried with Flexprop, loadp2:
Tried also with the Parallax Tool. On F11 it just gives the message about successful compilation and load.
I checked the datasheet hundred times. Probably a very stupid question, but... how can I get P2 to execute from flash after a reset?
loadp2 on it's own can't program flash. Need to use some weird command line to pre-pend the flash loader onto the application. Propeller Tool should work though.
Also, flash boot might not work with an SD card inserted.
Yes, it is puzzling. The Propeller Tool says it is done, but it works only until reset. Is there any way at all to verify the content of the flash?
Btw, booting from the SD works fine
SD will interfere when there is a valid boot file. Otherwise no problem, afaik.
Making an EEPROM image using loadp2 requires using the
P2ES_flashloader.spin2installer program. I think there is multiple ways to append files in either source form or binaries, but basically the target code is appended to the end of P2ES_flashloader.spin2 and thesizeparameter is set correctly then it should write itself to EEPROM when loaded into the Prop2.NOTE: My smartpin addition to it was a little over zealous with the unnecessary use of DualSPI interface mode. I made it faster than I should have on something that really needed widest compatibility. There is something like six different modes out there. Needless to say there are some EEPROMs that don't support DualSPI. Although tests show, I think, most failed boots are a compatibility problem in the ROM's EEPROM probing routine failing to elicit a response.
ManAtWork had a conversation running with a list of tested EEPROMs. I'm guessing it was in his KISS board topic ...
EDIT: This looks like it - https://forums.parallax.com/discussion/171108/spi-boot-rom-compatibility-tests/p1
S25FL256SAGB which I am using in the Stamp is not on that list
This is a great result. Glad your HyperRAM is working well @knivd.
Maybe you have V2 HyperRAM if your default latency is different. That different default setup is not yet put into my drivers although I think there was an API you can call to change it or a file change might be required. Perhaps if it is initialisation related it needed special attention beforehand for it to work, unfortunately it's been quite a while since I even looked at this stuff and have not had V2 HyperRAM to try out in person to date.
Yes, I admit that during the design phase I selected the components on the basis of hardware suitability rather than pre-existing support. My hope is that if the module is proven good for high-end real world applications, that support will gradually appear (including input from myself with me improving on the software side with the time).
It is not without problems, but as you know hardware almost never is. Fortunately, so far those problems are all solvable - software adjustments for the HyperRAM, probably the same for the flash, or in the worst case scenario I can change to something else in the same package - W25Q512JVBIQ for example, which is from the already verified Winbond's W25Q series. All will come in place with time.
I don't think this is V2 specific - the ISSI V1 part has the same config register, the newer Winbond part just defaults to 7 instead of 6 (presumably to match the higher clock speeds it supports).
To optimise my testing process I made a simple P2-STAMP breakout board.
It is basically just headers out of the module, and the headers can be installed in several different ways - horizontal, vertical, or in two distanced lines for prototyping board compatibility.
I will put the gerbers of this one in the same github repo as the module itself.
Have been playing a bit with TAQOZ, and it turns out it can write and read from the module's flash without any issues. But not FlexProp can't, despite issuing a message for successful operation
I then took one of these W25Q512JVBIQ, and manually replaced it on one module. Same result - TAQOZ happy and successful, FlexProp also happy, but not successful.
Starting to think that I am not doing something right... Is there any hidden secrets to program a .spin2 file into the flash memory, and then make it run on power up?
Sometimes the stage 2 loader has issues. Try this one. It's simplified to run at RCFAST and uses standard SPI, not dual data lines. https://forums.parallax.com/discussion/comment/1525737#Comment_1525737 That avoids a few points of failure.
Some flash chips need a pulldown on P58. The bootloader uses pullups and pulldowns on P59-61 to select the boot mode.
You don't want to program a .spin2 file, you want to program a .binary file. I make that mistake occasionally when using loadp2 from the command line. If you're using flexprop it's unlikely this is the issue.
I'd make a breakout similar to, and compatible with, the Eval Boards. Besides the connector compatibility, you get much better high-speed signal behaviour then. And it'll serve as a great replacement since Parallax seem to be discontinuing the reference Eval Board itself.
In fact I still think Parallax should pick up the Stamp as a stocked line in their shop.