@rogloh said:
I do wonder what the performance would be without the test board wiring attached to the same pins as the HyperRAM data.
Oh? I hadn't even bothered to look at that. Those tracks definitely should not be anywhere else other than the hyperRAM. That's grounds for a new Stamp layout then.
I will change that resistor value in next revision D. To be honest, I don't remember why it is 300R. In general, I kept very close to Parallax's original design, and maybe have just forgotten to change the value after a copy-paste... Interestingly, it didn't give me any problem during my tests, but assuing it was just a borderline success.
Regarding the HyperRAM, it is normal to assume that if the module uses it at maximum speed, that would be accounted for in the external connections. The current breakout board is definitely NOT the best carrier for such tests.
Btw, it is possible to remove the module from a socket. I have done it several times. There are good tools for removing PLCC chips, but it can be done even with a very thin screwdriver by sequentially lifting slightly each of the two exposed corners in the slotted corners of the socket.
@knivd said:
Btw, it is possible to remove the module from a socket. I have done is several times. There are good tools for removing PLCC chips, but it can be done even with a very thin screwdriver by sequentially lifting slightly each of the two exposed corners in the slotted corners of the socket.
Good to know. I was about to forgo the socket and just solder my Stamp to some wires.
@knivd said:
Btw, it is possible to remove the module from a socket. I have done it several times. There are good tools for removing PLCC chips, but it can be done even with a very thin screwdriver by sequentially lifting slightly each of the two exposed corners in the slotted corners of the socket.
Okay thanks for that information, glad to hear it can be done if required.
Apart from the HyperRAM I also got the built in RTC communicating tonight with some reasonable register responses. Didn't check the total clock functionality just the basic access and that what was returned made some sense.
One thing I was wondering about though was if the CS pin 57 from the P2 feeding the RTC floated low it might cause this chip to be accessed during flash/SD accesses when the P2 boots up. It might interfere with the data by trying to drive the P58 pin. Nothing in the schematic seems to directly pull it high unless the SN74LVC1G126 itself does that inherently.
Not yet tried the flash or SD on this module but do intend to, to check if the 300 ohm resistor causes issues for me as well.
@rogloh said:
One thing I was wondering about though was if the CS pin 57 from the P2 feeding the RTC floated low it might cause this chip to be accessed during flash/SD accesses when the P2 boots up. It might interfere with the data by trying to drive the P58 pin. Nothing in the schematic seems to directly pull it high unless the SN74LVC1G126 itself does that inherently.
You are right! A pullup resistor should be there. The same stands for P46 as well, while R8 and R15 would not be needed in such case, so I can repurpose them with new connections.
Looking at it, would it be a good idea to add pull-ups to P60 and P61 as well? R3 can do one of those, so only one extra may be needed in fact.
@knivd said:
Looking at it, would it be a good idea to add pull-ups to P60 and P61 as well? R3 can do one of those, so only one extra may be needed in fact.
You'll need to work it in with whatever combinations of flash/SD/serial boot you wish to support. If you do pull up P61 I think it may prevent the SD from booting won't it? Also you have P59 connected to a LED and the power regulator which could potentially complicate things further.
I have a feeling your current scheme with the tri-state buffers may prevent a P2 that is booting from an SD card from also flashing the P2 unless you dynamically change the state of the BOOT0 pin after P2 boots off the SD card. Sometimes people may want to be able to access both devices (flash and SD) after P2 bootup independent of the boot source even though there can be some limitations doing so. However this is a design choice and you could make their use fully exclusive of each other if you wanted to restrict it in that way.
For example, what if someone wanted to create a data logger that boots from flash (for reliability) but writes to uSD card? Given you have heaps of RAM and an RTC this P2-Stamp could be quite a good data logger. EDIT: actually your current HW should already support that case. It's the reverse case that looks like it wouldn't work (boot from SD, but also want to access flash later at runtime).
Interestingly if you choose to run the HyperRAM clock unregistered you can extend the sysclk/1 transfer range of the HyperRAM up above 328MHz on the P2-Stamp (albeit with a gap of non-working P2 clock frequencies from 314-326MHz). Maybe this is what @Wuerfel_21 does if she can get NeoYume working at sysclk/1 with this HyperRAM setup? Looks reasonably clean around 330-340MHz or so and I think that is around where NeoYume clocks the P2.
Oh and if anyone wants to replicate this and test their own P2-Stamp HyperRAM with my 0.9b driver here are the patches/hacks I applied to my driver and delaytest.spin2 file to allow it to work until proper support is put in. EDIT: couldn't quote the diff without format messing up, had to screenshot it.
But to make the P2 actually start from flash you need to pull P61 high with a pull up while you reset the P2.
These P2-Stamp schematic notes say floating or pulling high BOOT0 will let it boot from flash, but doing that alone is insufficient as P61 is not driven (it's only a floating IO pin on this board). According to the boot pattern table I posted above it needs to pulled up high with a resistor for the module to really boot from flash. Once you do that step the P2 will start up from your flashed image. If this scheme is going to be altered with resistor changes etc, I think it would be good to only have to mess around with the exposed BOOTx pins to select the actual boot mode, not the other P2 pins externally. Whether or not that can be achieved easily with minimal changes is TBD.
I'm still yet to mess with uSD boot to see if I suffer the same fate as Wuerfel_21 did.
UPDATE: yeah so far no luck. I was apparently able to write to the uSD card from the P2 with loadp2 and the P2ES_sdcard.bin loader program but it wouldn't boot up from it. When I read the file back from this uSD on my host Mac and compared it to the binary what was written, it had some different data. Maybe that is normal for this stuff, putting extra headers on etc, not sure. Also tried writing the binary _BOOT_P2.BIX file directly to this card from the host Mac and then booting off it that way, but it still wouldn't run the application. If I can source a small enough 1k2 SMD resistor (they are TINY) I could try to parallel solder it to drop R4 from 300 down to 240 ohms.
Shortly after my previous post, I realised that my thoughts yesterday were not valid. Exactly due to the tristate nature of the 1G26's output. I can of course swap it for 1G97, and that would then work. Or just add a couple more resistors.
The original reason why I did it this way, was to allow those ports being used as analog in systems which don't need RTC or HyperRAM, and with the assumption that the Stamp is not a SBC and the hosting system will provide the necessary external resistors for its proper operation.
But reassessing that again, the probability of that combined with the need for those exact ports is pretty low,
Regarding booting from the SD, I never saw any issues with that. It was the flash where I struggled to boot from, and now it is clear why (external resistor needed).
@knivd said:
Regarding booting from the SD, I never saw any issues with that. It was the flash where I struggled to boot from, and now it is clear why (external resistor needed).
Did your board also have the 300 ohms R4 fitted? I'm still to be convinced it's too high for a P2 to boot off the SD - okay maybe flexspin is tweaked finely to make a difference but the P2 should still boot as I don't expect the boot code is clocked really fast to have rise/fall time issues.
@rogloh said:
Did your board also have the 300 ohms R4 fitted? I'm still to be convinced it's too high for a P2 to boot off the SD - okay maybe flexspin is tweaked finely to make a difference but the P2 should still boot as I don't expect the boot code is clocked really fast to have rise/fall time issues.
Ok tried a different SanDisk uSD card (usual BS) and was able to get the P2 to boot from it now. So all peripherals are apparently able to function on this module under the right circumstances which is very good.
Though the right circumstances might include not using flexspin for SD read/write..
If you want to experiment with Flexspin support at lowered SD clock rate then just have to adjust ck_div setting in disk_initialize() function of include/filesys/fatfs/sdmm.cc
EDIT: The default of sysclock/16 would be a good starting point. Comment out lines 589 to 597.
The ten high speed connections to the hyperRAM really should be completely excluded from the off-Stamp I/O. That frees up the NORAM contact as well. Redistribute those contacts to increase ground count and maybe have four VIO supply contacts, one for each side of the Prop2.
I definitely find those DIN logic symbols used in your schematic to be confusing. I couldn't make head nor tail without looking them up. In fact I didn't even know DIN had a standard symbol set. They conflict badly with the US MIL/ANSI symbols. At least IEC is clearly different with their's.
The easiest way to make sense, I found, was to look up an ancient 74 series databook for the matching 74 numbers in there.
@evanh said:
The ten high speed connections to the hyperRAM really should be completely excluded from the off-Stamp I/O. That frees up the NORAM contact as well. Redistribute those contacts to increase ground count and maybe have four VIO supply contacts, one for each side of the Prop2.
Hmmm, I am not sure about that. Focusing on getting the highest speed for the sake of benchmarks, is always on the expense of practicality. Looking from that point of view, not all real-world applications require HyperRAM, and even less require HyperRAM working at its absolute maximum speed. In many cases it may not be needed at all, but more I/O ports instead.
@evanh said:
I definitely find those DIN logic symbols used in your schematic to be confusing. I couldn't make head nor tail without looking them up. In fact I didn't even know DIN had a standard symbol set. They conflict badly with the US MIL/ANSI symbols. At least IEC is clearly different with their's.
@knivd said:
Hmmm, I am not sure about that. Focusing on getting the highest speed for the sake of benchmarks, is always on the expense of practicality.
This is totally intended for reliability. But it's also true I don't know how reliable we can get.
@evanh said:
I definitely find those DIN logic symbols used in your schematic to be confusing. I couldn't make head nor tail without looking them up. In fact I didn't even know DIN had a standard symbol set. They conflict badly with the US MIL/ANSI symbols. At least IEC is clearly different with their's.
What are you referring to?
You've got four "tiny" logic gates sprinkled around the Stamp for chip-select functions.
@knivd said:
Hmmm, I am not sure about that. Focusing on getting the highest speed for the sake of benchmarks, is always on the expense of practicality.
This is totally intended for reliability. But it's also true I don't know how reliable we can get.
I guess snapping off those contacts around the Stamp is an option I should work with.
@knivd said:
What would be the best way to arrange those on-board resistors in rev.D so they cover the most usecase scenarios?
Looking at the table, it appears that if you had resistors connected to P61 and P59 and exposed their other ends as BOOT0 and BOOT1, then you could either strap them high or low or float them externally and you'd have most boot cases handled. The pullup on P60 is internal to the SD card and is only there when a card is fitted. You may not even need a tri-state buffer in this case or figure another way to enable it based on the BOOT pin state?
You also want to sort out the floating P57 RTC CS and the HyperRAM CS pin as previously mentioned, perhaps with an OR gate instead so a second floating input doesn't cause output problems (though floating CMOS input pins are not good in general for power use).
@rogloh said:
Interestingly if you choose to run the HyperRAM clock unregistered you can extend the sysclk/1 transfer range of the HyperRAM up above 328MHz on the P2-Stamp (albeit with a gap of non-working P2 clock frequencies from 314-326MHz). Maybe this is what @Wuerfel_21 does if she can get NeoYume working at sysclk/1 with this HyperRAM setup? Looks reasonably clean around 330-340MHz or so and I think that is around where NeoYume clocks the P2.
NeoYume has never had sysclk/1 support. Always syclk/2 for HyperRAM. Very reliable at that speed. Have had the stamp running for days almost uninterrupted. No crashes.
@evanh said:
Ada didn't explicitly say it was a SD boot problem. I interpreted it as she had to use the addon SD slot for post-boot game loading.
Yes. It'd boot about 75% of the time (with fast loader stub!), but then fail loading the actual data.
Looking at this table, I am really puzzled why P2 is missing the two most important patterns for embedded application - flash->SD->shutdown and SD->flash->shutdown...
Instead, it seems to be offering multiple serial boot configurations which I can't really see that much useful
Yea, I think it only ever tries one or the other. However, nothing stops a flash booted program from looking for an SD boot file itself (which is probably more useful than the ROM loader since it can display error messages to somewhere).
So, according to the current Stamp schematic, and assuming I add a weak pullup on P61 in the next revision, this is what I think the boot configurations should look like:
BOOT0 BOOT1
Z/1 Z (default) serial->flash
Z/1 0 flash
Z/1 1 serial
0 Z SD->serial
0 0 SD
0 1 serial
@evanh said:
A pull-up on P61 will knock out the SD options I believe.
Maybe eliminate U1 and make BOOT0 like BOOT1 and have it be a 10k resistor for both pull-up and pull-down of P61.
Yeah that's what I had suggested too. My only concern was the floating CS pin on the flash and I still wondered if some U1 device could be useful as a buffer to isolate the flash CS wire from P61. The problem is we need a gate that copies a floating state from input to output and lets true high/low states pass through. You want this combination from input -> output (flash side) I don't know of a regular gate like that unless you made it a comparator with low threshold voltage.
Z -> 1 or Z, doesn't matter which as there is already a pullup on the output side
1 -> 1
0 -> 0
I went and checked the P2-EVAL schematic thinking it may have solved this same CS pin issue somehow. It does it by decoupling the flash CS pin with a DIP switch from P61 and has a pullup on the flash side of the switch but if you want to boot from SD you have to fully disable flash (so you can't use flash at runtime unless you manually flip the DIP switch back - which at least is still doable in a pinch). I guess for the P2-stamp you could put your BOOT0 pin though a switch on the motherboard housing the P2-Stamp to then allow some re-flashing of a bricked device state from a file - which is the use case I think would be desirable here. i.e. Some embedded device is bricked, and needs to be re-flashed from some downloaded restoration boot file loaded onto a uSD card. This is a special case, as a working device would already have a way to upgrade itself off uSD if it can already boot from flash first.
@evanh said:
A pull-up on P61 will knock out the SD options I believe.
It shouldn't, because I will put a weak pullup, so an outside strong one to ground will satisfy the condition to boot from SD.
@rogloh said:
Z -> 1 or Z, doesn't matter which as there is already a pullup on the output side
1 -> 1
0 -> 0
This is precisely why U1 is there - to achieve that output.
Essentially, a weak pullup on P61 will only make boot from flash a defalt option as opposed to the current (already verified) situation where it needs to be outside.
Comments
Oh? I hadn't even bothered to look at that. Those tracks definitely should not be anywhere else other than the hyperRAM. That's grounds for a new Stamp layout then.
I will change that resistor value in next revision D. To be honest, I don't remember why it is 300R. In general, I kept very close to Parallax's original design, and maybe have just forgotten to change the value after a copy-paste... Interestingly, it didn't give me any problem during my tests, but assuing it was just a borderline success.
Regarding the HyperRAM, it is normal to assume that if the module uses it at maximum speed, that would be accounted for in the external connections. The current breakout board is definitely NOT the best carrier for such tests.
Btw, it is possible to remove the module from a socket. I have done it several times. There are good tools for removing PLCC chips, but it can be done even with a very thin screwdriver by sequentially lifting slightly each of the two exposed corners in the slotted corners of the socket.
Good to know. I was about to forgo the socket and just solder my Stamp to some wires.
Okay thanks for that information, glad to hear it can be done if required.
Apart from the HyperRAM I also got the built in RTC communicating tonight with some reasonable register responses. Didn't check the total clock functionality just the basic access and that what was returned made some sense.
One thing I was wondering about though was if the CS pin 57 from the P2 feeding the RTC floated low it might cause this chip to be accessed during flash/SD accesses when the P2 boots up. It might interfere with the data by trying to drive the P58 pin. Nothing in the schematic seems to directly pull it high unless the SN74LVC1G126 itself does that inherently.
Not yet tried the flash or SD on this module but do intend to, to check if the 300 ohm resistor causes issues for me as well.
You are right! A pullup resistor should be there. The same stands for P46 as well, while R8 and R15 would not be needed in such case, so I can repurpose them with new connections.
Looking at it, would it be a good idea to add pull-ups to P60 and P61 as well? R3 can do one of those, so only one extra may be needed in fact.
You'll need to work it in with whatever combinations of flash/SD/serial boot you wish to support. If you do pull up P61 I think it may prevent the SD from booting won't it? Also you have P59 connected to a LED and the power regulator which could potentially complicate things further.
I have a feeling your current scheme with the tri-state buffers may prevent a P2 that is booting from an SD card from also flashing the P2 unless you dynamically change the state of the BOOT0 pin after P2 boots off the SD card. Sometimes people may want to be able to access both devices (flash and SD) after P2 bootup independent of the boot source even though there can be some limitations doing so. However this is a design choice and you could make their use fully exclusive of each other if you wanted to restrict it in that way.
For example, what if someone wanted to create a data logger that boots from flash (for reliability) but writes to uSD card? Given you have heaps of RAM and an RTC this P2-Stamp could be quite a good data logger. EDIT: actually your current HW should already support that case. It's the reverse case that looks like it wouldn't work (boot from SD, but also want to access flash later at runtime).
Interestingly if you choose to run the HyperRAM clock unregistered you can extend the sysclk/1 transfer range of the HyperRAM up above 328MHz on the P2-Stamp (albeit with a gap of non-working P2 clock frequencies from 314-326MHz). Maybe this is what @Wuerfel_21 does if she can get NeoYume working at sysclk/1 with this HyperRAM setup? Looks reasonably clean around 330-340MHz or so and I think that is around where NeoYume clocks the P2.
Oh and if anyone wants to replicate this and test their own P2-Stamp HyperRAM with my 0.9b driver here are the patches/hacks I applied to my driver and delaytest.spin2 file to allow it to work until proper support is put in. EDIT: couldn't quote the diff without format messing up, had to screenshot it.
I was just able to get this rev A P2-stamp module to program its flash (S25FL256S) using the P2ES_flashloader binary distributed with flexprop:
But to make the P2 actually start from flash you need to pull P61 high with a pull up while you reset the P2.
These P2-Stamp schematic notes say floating or pulling high BOOT0 will let it boot from flash, but doing that alone is insufficient as P61 is not driven (it's only a floating IO pin on this board). According to the boot pattern table I posted above it needs to pulled up high with a resistor for the module to really boot from flash. Once you do that step the P2 will start up from your flashed image. If this scheme is going to be altered with resistor changes etc, I think it would be good to only have to mess around with the exposed BOOTx pins to select the actual boot mode, not the other P2 pins externally. Whether or not that can be achieved easily with minimal changes is TBD.
I'm still yet to mess with uSD boot to see if I suffer the same fate as Wuerfel_21 did.
UPDATE: yeah so far no luck. I was apparently able to write to the uSD card from the P2 with loadp2 and the P2ES_sdcard.bin loader program but it wouldn't boot up from it. When I read the file back from this uSD on my host Mac and compared it to the binary what was written, it had some different data. Maybe that is normal for this stuff, putting extra headers on etc, not sure. Also tried writing the binary _BOOT_P2.BIX file directly to this card from the host Mac and then booting off it that way, but it still wouldn't run the application. If I can source a small enough 1k2 SMD resistor (they are TINY) I could try to parallel solder it to drop R4 from 300 down to 240 ohms.
Shortly after my previous post, I realised that my thoughts yesterday were not valid. Exactly due to the tristate nature of the 1G26's output. I can of course swap it for 1G97, and that would then work. Or just add a couple more resistors.
The original reason why I did it this way, was to allow those ports being used as analog in systems which don't need RTC or HyperRAM, and with the assumption that the Stamp is not a SBC and the hosting system will provide the necessary external resistors for its proper operation.
But reassessing that again, the probability of that combined with the need for those exact ports is pretty low,
Regarding booting from the SD, I never saw any issues with that. It was the flash where I struggled to boot from, and now it is clear why (external resistor needed).
Did your board also have the 300 ohms R4 fitted? I'm still to be convinced it's too high for a P2 to boot off the SD - okay maybe flexspin is tweaked finely to make a difference but the P2 should still boot as I don't expect the boot code is clocked really fast to have rise/fall time issues.
Yes, R4 is 300R in all modules made until now
Ada didn't explicitly say it was a SD boot problem. I interpreted it as she had to use the addon SD slot for post-boot game loading.
Ok tried a different SanDisk uSD card (usual BS) and was able to get the P2 to boot from it now. So all peripherals are apparently able to function on this module under the right circumstances which is very good.
Though the right circumstances might include not using flexspin for SD read/write..
If you want to experiment with Flexspin support at lowered SD clock rate then just have to adjust
ck_divsetting indisk_initialize()function ofinclude/filesys/fatfs/sdmm.ccEDIT: The default of sysclock/16 would be a good starting point. Comment out lines 589 to 597.
#ifdef _smartpins_mode_eh tmr = _clockfreq(); spm_tx |= P_INVERT_B; // Performance option for "Default Speed" (Up to 50 MHz SPI clock) if( tmr <= 150_000_000 ) ck_div = 0x0002_0004; // sysclock/4 else if( tmr <= 200_000_000 ) ck_div = 0x0002_0005; // sysclock/5 else if( tmr <= 280_000_000 ) ck_div = 0x0002_0006; // sysclock/6 else ck_div = 0x0003_0008; // sysclock/8 #endifWhat would be the best way to arrange those on-board resistors in rev.D so they cover the most usecase scenarios?
The ten high speed connections to the hyperRAM really should be completely excluded from the off-Stamp I/O. That frees up the NORAM contact as well. Redistribute those contacts to increase ground count and maybe have four VIO supply contacts, one for each side of the Prop2.
I definitely find those DIN logic symbols used in your schematic to be confusing. I couldn't make head nor tail without looking them up. In fact I didn't even know DIN had a standard symbol set. They conflict badly with the US MIL/ANSI symbols. At least IEC is clearly different with their's.
The easiest way to make sense, I found, was to look up an ancient 74 series databook for the matching 74 numbers in there.
Hmmm, I am not sure about that. Focusing on getting the highest speed for the sake of benchmarks, is always on the expense of practicality. Looking from that point of view, not all real-world applications require HyperRAM, and even less require HyperRAM working at its absolute maximum speed. In many cases it may not be needed at all, but more I/O ports instead.
What are you referring to?
This is totally intended for reliability. But it's also true I don't know how reliable we can get.
You've got four "tiny" logic gates sprinkled around the Stamp for chip-select functions.
I guess snapping off those contacts around the Stamp is an option I should work with.
Looking at the table, it appears that if you had resistors connected to P61 and P59 and exposed their other ends as BOOT0 and BOOT1, then you could either strap them high or low or float them externally and you'd have most boot cases handled. The pullup on P60 is internal to the SD card and is only there when a card is fitted. You may not even need a tri-state buffer in this case or figure another way to enable it based on the BOOT pin state?
You also want to sort out the floating P57 RTC CS and the HyperRAM CS pin as previously mentioned, perhaps with an OR gate instead so a second floating input doesn't cause output problems (though floating CMOS input pins are not good in general for power use).
NeoYume has never had sysclk/1 support. Always syclk/2 for HyperRAM. Very reliable at that speed. Have had the stamp running for days almost uninterrupted. No crashes.
Yes. It'd boot about 75% of the time (with fast loader stub!), but then fail loading the actual data.
Looking at this table, I am really puzzled why P2 is missing the two most important patterns for embedded application - flash->SD->shutdown and SD->flash->shutdown...
Instead, it seems to be offering multiple serial boot configurations which I can't really see that much useful
Yea, I think it only ever tries one or the other. However, nothing stops a flash booted program from looking for an SD boot file itself (which is probably more useful than the ROM loader since it can display error messages to somewhere).
So, according to the current Stamp schematic, and assuming I add a weak pullup on P61 in the next revision, this is what I think the boot configurations should look like:
A pull-up on P61 will knock out the SD options I believe.
Maybe eliminate U1 and make BOOT0 like BOOT1 and have it be a 10k resistor for both pull-up and pull-down of P61.
Yeah that's what I had suggested too. My only concern was the floating CS pin on the flash and I still wondered if some U1 device could be useful as a buffer to isolate the flash CS wire from P61. The problem is we need a gate that copies a floating state from input to output and lets true high/low states pass through. You want this combination from input -> output (flash side) I don't know of a regular gate like that unless you made it a comparator with low threshold voltage.
Z -> 1 or Z, doesn't matter which as there is already a pullup on the output side
1 -> 1
0 -> 0
I went and checked the P2-EVAL schematic thinking it may have solved this same CS pin issue somehow. It does it by decoupling the flash CS pin with a DIP switch from P61 and has a pullup on the flash side of the switch but if you want to boot from SD you have to fully disable flash (so you can't use flash at runtime unless you manually flip the DIP switch back - which at least is still doable in a pinch). I guess for the P2-stamp you could put your BOOT0 pin though a switch on the motherboard housing the P2-Stamp to then allow some re-flashing of a bricked device state from a file - which is the use case I think would be desirable here. i.e. Some embedded device is bricked, and needs to be re-flashed from some downloaded restoration boot file loaded onto a uSD card. This is a special case, as a working device would already have a way to upgrade itself off uSD if it can already boot from flash first.
It shouldn't, because I will put a weak pullup, so an outside strong one to ground will satisfy the condition to boot from SD.
This is precisely why U1 is there - to achieve that output.
Essentially, a weak pullup on P61 will only make boot from flash a defalt option as opposed to the current (already verified) situation where it needs to be outside.
This is what I think rev.D would look like.