The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.
A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
I requested an autobaud echo some time ago, but that never made the cut. Such an echo is useful for fastest reset exit from a host-boot MCU.
The shortest query to get a response response string from the booter is the "> Prop_Chk 0 0 0 0 " which echoes 13,10,"Prop_Ver ","A",13,10
A waiting host MCU can send "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 "..
There may be shorter ones that can hop to other parts of ROM, and hop back to booter ?
Not clear if those shorter ones could work as packed strings at the full baud rate ? ie some delays might be required.
I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
The SD card has the pull-up built-in.
I will modify PNut soon to allow for longer
response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
v32i seems to be working on my DE2-115; at least, I'm able to get into TAQOZ and the P2-MONITOR.
The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.
A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
At the end of it we still had a whopping 58 bytes "wasted" It might be an idea to allow for it in the next ROM source as an option (just in case). I will be testing better versions of the ROM (just in case).
BAD SD CARD BOOT - 100ms
I've popped an old 256M card in and booted the P2 which of course fails SD boot. I've then been able to go into TAQOZ and confirm boot failure. The time from first boot activity to fail is about 100ms. ( I will do another post for a good card but no boot files as it will take longer to boot) (Also another one for pull-up only)
Confirming SD detection and failure:
Cold start
----------------------------------------------------------------
Parallax P2 .:.:--TAQOZ--:.:. V1.0--142 180530-0135
----------------------------------------------------------------
TAQOZ# SD? . -1 ok
TAQOZ# !SD .L $0000_0000 ok
TAQOZ# 0 0 cmd . 1 ok
It responds to a CMD0 which says it is a real SD card.
Next I force a crc just for this command since it is still in SD mode and check CMD8.
TAQOZ# $87 $34 C! ok
TAQOZ# $1AA 8 CMD .W $0005 ok
I repeatedly test but we need a response of 1 and this old card is not able to accommodate a $1AA capabilities.
No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.
My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
PULL-UP on SD CS but no SD - 2ms
The case of a pull-up on SD CS but no SD isn't too bad. Most of the time seems to be taken up with the slow clocking before checking which I am fairly sure is not required of SDHC cards. However, it is only 2ms.
Confirming the pullup where SD? tests for a pullup and returns true/false where -1 is true. Then CMD0 with data of 0 (0 0 CMD) returns with 0 which could even be $FF if it were pulled up on the DO line but we are looking for a $01.
TAQOZ# SD? . -1 ok
TAQOZ# 0 0 CMD . 0 ok
Confirming that slow clocking is NOT required I insert a card, check it for pull-up, and issue a raw CMD0 without anything else.
TAQOZ# SD? . -1 ok
TAQOZ# 0 0 CMD . 63 ok
TAQOZ# 0 0 CMD . 193 ok
TAQOZ# 0 0 CMD . 1 ok
The card responded after the 3rd try which is well within what we expect and allow for. Timing this without clocking:
TAQOZ# BEGIN SD? UNTIL 5 ms LAP BEGIN 0 0 CMD 1 = UNTIL LAP .LAP 8475 cycles = 105.937us ok
Type a ^X to repeat the last line executed returns the exact same result:
TAQOZ# 8475 cycles = 105.937us ok
So we could know within around 100us or so that it is a real SD card.
I will modify PNut soon to allow for longer response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
is there any down side to having a longer timeout ?
Or you could simply continually repeat send of the Autobaud + query, checking for a reply - that auto-adjusts to any variable path delays.
You could allow the user to stop after some seconds, or just have some umbrella timeout
SD BOOT - NEW BLANK FAT32 - 193ms
Now here's another boot fail case I added, one where we insert a brand new FAT32 card that is blank. The SD booter still goes through the motions looking for a raw file before checking the root directory which is blank. Total time spent here is 193ms.
Confirming it is blank and nothing, not even deleted entries in the root directory:
NON-FAT32 SD BOOT FAIL - 320ms
I tried formatting an SD card to NTFS just to give the SD booter something tough to chew on. It seems NTFS is just unpleasant with a timeout of 320ms.
TAQOZ# SD? . -1 ok
TAQOZ# !sd .L $C0FF_8000 ok
TAQOZ# MOUNT ...NCard 0000_0100 Y u q 4k 0M ok
TAQOZ# DIR
...NCard 0000_0100 Y u q 4k 0M
ok
TAQOZ#
FAT32 - MANY FILES BUT NO BOOT - 244ms
I noticed that this old 4G card had been formatted in a PC incorrectly. Always use a proper SD Formatter utility.
Nonetheless, after searching the root directory it timed out after 244ms.
I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one. When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one.
When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
A blind scan is useful for easily setting things up initially, but it's not going to be the default development loop, surely ?
Few would want all serial ports being messed with.
Options are to save the port the P2 was found on, in a file, and start there next time, and to support command line param saying which explicit port to use ?
You could alternatively do 2 scan passes, one more rapid one that expects serial-default, and then a slower one for the fall-back choices ?
Jmg, yes, the last-working port is remembered during the run-life of PNut.exe. The first download takes a bit longer than the rest. We could bother to save the port number to disk, as well.
Hey Chip, do you think you could update the front page of the docs with an image of the P2 chip artwork including a status box outlining that the chip and P2 ROM have been submitted and a rider about the hazards of internal "alpha" sampling but with a confident note about the expected positive outcome and maybe when chips are available etc? The image will make it seem more real to many. A block diagram up here would also be super.
I'd like to use this document as a reference but if you also publish this Google doc it will be more readily accessible to those who are just casually perusing the document and if you include a link in your document to this pub doc and vice versa then anyone can click to see the original etc.
Peter, I sort of did it. No talk about "alpha sampling", though.
Thanks, I was thinking of a "fine print" rider, maybe down in a footer just so they've been told and you are covered since everyone will ask
"Great! but when?".
As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
Looks good, Peter. Jazz it up if you want and we can put it in there.
Keep an eye on the drawing file in the P2/docs dropbox folder. There's also a pdf version that I will keep updating. Just for now, these are the bits I'm playing with but I'm a long way off yet (complete with errors - for the moment)
Updated!
Along with the CORDIC and PRGN, there is also CT counter and the LOCK flags. That would round it off. There is plenty more but it would just get messy I'd say.
No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.
My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
Comments
The shortest query to get a response response string from the booter is the "> Prop_Chk 0 0 0 0 " which echoes 13,10,"Prop_Ver ","A",13,10
A waiting host MCU can send "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 "..
There may be shorter ones that can hop to other parts of ROM, and hop back to booter ?
Not clear if those shorter ones could work as packed strings at the full baud rate ? ie some delays might be required.
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
The SD card has the pull-up built-in.
I will modify PNut soon to allow for longer
response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
At the end of it we still had a whopping 58 bytes "wasted"
I've popped an old 256M card in and booted the P2 which of course fails SD boot. I've then been able to go into TAQOZ and confirm boot failure. The time from first boot activity to fail is about 100ms. ( I will do another post for a good card but no boot files as it will take longer to boot) (Also another one for pull-up only)
Confirming SD detection and failure: It responds to a CMD0 which says it is a real SD card.
Next I force a crc just for this command since it is still in SD mode and check CMD8. I repeatedly test but we need a response of 1 and this old card is not able to accommodate a $1AA capabilities.
My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
The case of a pull-up on SD CS but no SD isn't too bad. Most of the time seems to be taken up with the slow clocking before checking which I am fairly sure is not required of SDHC cards. However, it is only 2ms.
Confirming the pullup where SD? tests for a pullup and returns true/false where -1 is true. Then CMD0 with data of 0 (0 0 CMD) returns with 0 which could even be $FF if it were pulled up on the DO line but we are looking for a $01.
Confirming that slow clocking is NOT required I insert a card, check it for pull-up, and issue a raw CMD0 without anything else. The card responded after the 3rd try which is well within what we expect and allow for. Timing this without clocking:
Type a ^X to repeat the last line executed returns the exact same result:
So we could know within around 100us or so that it is a real SD card.
is there any down side to having a longer timeout ?
Or you could simply continually repeat send of the Autobaud + query, checking for a reply - that auto-adjusts to any variable path delays.
You could allow the user to stop after some seconds, or just have some umbrella timeout
Now here's another boot fail case I added, one where we insert a brand new FAT32 card that is blank. The SD booter still goes through the motions looking for a raw file before checking the root directory which is blank. Total time spent here is 193ms.
Confirming it is blank and nothing, not even deleted entries in the root directory:
I tried formatting an SD card to NTFS just to give the SD booter something tough to chew on. It seems NTFS is just unpleasant with a timeout of 320ms.
I noticed that this old 4G card had been formatted in a PC incorrectly. Always use a proper SD Formatter utility.
Nonetheless, after searching the root directory it timed out after 244ms.
I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one. When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
A blind scan is useful for easily setting things up initially, but it's not going to be the default development loop, surely ?
Few would want all serial ports being messed with.
Options are to save the port the P2 was found on, in a file, and start there next time, and to support command line param saying which explicit port to use ?
You could alternatively do 2 scan passes, one more rapid one that expects serial-default, and then a slower one for the fall-back choices ?
Looks good. Thanks, Peter.
I'd like to use this document as a reference but if you also publish this Google doc it will be more readily accessible to those who are just casually perusing the document and if you include a link in your document to this pub doc and vice versa then anyone can click to see the original etc.
"Great! but when?".
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
Looks good, Peter. Jazz it up if you want and we can put it in there.
Updated!
It is looking kind of like a sunflower.
Along with the CORDIC and PRGN, there is also CT counter and the LOCK flags. That would round it off. There is plenty more but it would just get messy I'd say.