TAQOZ is a very easy way to check out hardware, both the P2 itself and whatever you have connected to it. TAQOZ has some SD utilities in ROM but they need further testing however if you paste in this file through your terminal with a line delay of 15ms (char delay = 0) it will give you the full FAT32 system. If you have Flash as well you can even BACKUP that into Flash. However with these tools you should be able to discover what is happening. I may add some diagnostic messages to that source file to make it easier to figure out what's going on. But try it for now.
----------------------------------------------------------------
TAQOZ# Parallax P2 .:.:--TAQOZ--:.:. V1.0 180519-1500
----------------------------------------------------------------
TAQOZ# ok
TAQOZ# lsio
P:00000000001111111111222222222233333333334444444444555555555566
P:01234567890123456789012345678901234567890123456789012345678901
=:d~~~ddddd~dd~~~~~~~~~~~~~~~~~~~~~~~~hhhdh~d~ddd~~~hdhhdd~~h~hh ok
TAQOZ# MOUNT
Mounted WIDGET 8C0D_A960-6338_6430 [SDSL08G] FAT32 7,944MB (32kB/cluster) ok
TAQOZ# ls
/WIDGET
DUMPV4 .FTH EASYFILE.FTH EASYNET .FTH EXTEND .FTH LIFE .FTH
LOVE .WAV POPCORN .WAV SEEDAWN .FTH SPLAT-V4.FTH TACHYO~1.SPI
WARPEACE.TXT ROM_136X.OBJ ok
TAQOZ# FOPEN ROM_136X.OBJ...opened at 0000_CE00 ok
TAQOZ# 0 $40 FS DUMPL
00000- FECF_C000 FAC4_1361 F8D0_0E09 FD60_0E00 '....a.........`.'
00010- F104_0E01 FB6C_11FB FD9F_FFFC 3000_0000 '......l........0'
00020- 0000_4000 0000_0000 0000_0000 0000_0000 '.@..............'
00030- 0000_0000 0000_0000 0000_0000 0000_0000 '................' ok
We are testing SD on the CVA9 as an external device but perhaps those who are not testing would like to use the internal card which requires boot pins mapped internal, which then means no Flash.
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
We are testing SD on the CVA9 as an external device but perhaps those who are not testing would like to use the internal card which requires boot pins mapped internal, which then means no Flash.
and no sd as there is a pullup on P59 too, so goes straight to serial
We are testing SD on the CVA9 as an external device but perhaps those who are not testing would like to use the internal card which requires boot pins mapped internal, which then means no Flash.
Oh!
I will have to put a breakout board together tomorrow.
Shame though, I also have a DE2-115 with a SD socket but no image is available for that.
I have in my collection of stuff a "Parallax Memory Card #40004" with SD and flash on board.
The board will need modification though as the card switch pills MOSI low.
I have in my collection of stuff a "Parallax Memory Card #40004" with SD and flash on board.
The board will need modification though as the card switch pills MOSI low.
Flick R2 off with a hot iron (and maybe a blob of solder) as it is never needed and will interfere with boot detection.
Garry, compile and download this program using pnut. If your SD had been working and there was valid boot code, this program would not run. So you would need to insert the SD card after the "Demo.." message while the program stalls waiting for operator input. Once you hit enter, the program will try the SD card and report a couple of status points reached. Let me know where it fails please, and I will break it down some more.
Renamed the file to run to "_BOOT_P2.BIZ".
At the "Demo..." prompt I insert the SDCard then Enter and get:
Init passed
MBR passed
DIR passed
No further messages appear, so it looks like something may be going awry in the monitor #readFILE routine, as I assume that "File failed" should be output if the call had returned with an error status?
I think it more likely that the file being loaded and run is broken. I posted some demo files to flash pins a few posts back.
You could also try this patch in the ROM to fix that missing wz. It applies to SD1 cards, and causes an error to be reported rather than continuing.
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
Can you lengthen the timeout, at least for now. It's probably more difficult to set a com port to use and allow more time.
Currently there is no way to load if an SD card is present.
In looking at the 4800 baud problem (it doesn't auto-baud that low), I see the problem.
Within autobaud_isr, the max measurement allowed is $58E4 ('limit'). This gets multiplied by $1_0000/7 = $2492 ('baud0'). The product is $0CB2C208. The top 16 bits become the bit period in system clocks: $0CB2 = 3250. At 20MHz, that's a maximum bit period of 3250 / 20M = 162.5us = 6153 baud. That's why 4800 baud fails, it's too slow. Really, that RC oscillator can run up to 30MHz in the fast corner. That would increase the minimum baud to 6153 * (30M/20M) = 9230 baud. So, 9600 baud needs to be considered as the lower baud limit for the auto-baud detector. At the other extreme, it can go up to 2M baud in the slow corner.
So, the actual auto-baud range for the booter must be declared as 9,600 to 2,000,000 baud. I will change the Google Doc now.
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
Can you lengthen the timeout, at least for now. It's probably more difficult to set a com port to use and allow more time.
Currently there is no way to load if an SD card is present.
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
Can you lengthen the timeout, at least for now. It's probably more difficult to set a com port to use and allow more time.
Currently there is no way to load if an SD card is present.
Okay. How long of a timeout do we need? 1 second?
I allow around half a second for SD cards so 1 second should be fine.
I also saw that 9600 baud limit the other day but I didn't consider it a problem. Now if you can't go above 4800 baud, now that is a problem
We are testing SD on the CVA9 as an external device but perhaps those who are not testing would like to use the internal card which requires boot pins mapped internal, which then means no Flash.
Oh!
I will have to put a breakout board together tomorrow.
Shame though, I also have a DE2-115 with a SD socket but no image is available for that.
I updated the FPGA-images-with-new-ROM file at the top of this thread and there's now a DE2-115 image. The SPI/SD pins (P61..P58) are mapped directly to the general-purpose I/O's, not the built-in SD card socket.
In looking at the 4800 baud problem (it doesn't auto-baud that low), I see the problem.
Within autobaud_isr, the max measurement allowed is $58E4 ('limit'). This gets multiplied by $1_0000/7 = $2492 ('baud0'). The product is $0CB2C208. The top 16 bits become the bit period in system clocks: ...
Is that a limit in the Smart Hardware (eg 16b Divider ?), or just a limit in the maths of a fitting the scale into a 32b result ?
In looking at the 4800 baud problem (it doesn't auto-baud that low), I see the problem.
Within autobaud_isr, the max measurement allowed is $58E4 ('limit'). This gets multiplied by $1_0000/7 = $2492 ('baud0'). The product is $0CB2C208. The top 16 bits become the bit period in system clocks: ...
Is that a limit in the Smart Hardware (eg 16b Divider ?), or just a limit in the maths of a fitting the scale into a 32b result ?
It's a limit of the math operations. Do you think we should make it work with lower bauds?
I updated the FPGA-images-with-new-ROM file at the top of this thread and there's now a DE2-115 image. The SPI/SD pins (P61..P58) are mapped directly to the general-purpose I/O's, not the built-in SD card socket.
I updated the FPGA-images-with-new-ROM file at the top of this thread and there's now a DE2-115 image. The SPI/SD pins (P61..P58) are mapped directly to the general-purpose I/O's, not the built-in SD card socket.
I updated the FPGA-images-with-new-ROM file at the top of this thread and there's now a DE2-115 image. The SPI/SD pins (P61..P58) are mapped directly to the general-purpose I/O's, not the built-in SD card socket.
In looking at the 4800 baud problem (it doesn't auto-baud that low), I see the problem.
Within autobaud_isr, the max measurement allowed is $58E4 ('limit'). This gets multiplied by $1_0000/7 = $2492 ('baud0'). The product is $0CB2C208. The top 16 bits become the bit period in system clocks: ...
Is that a limit in the Smart Hardware (eg 16b Divider ?), or just a limit in the maths of a fitting the scale into a 32b result ?
It's a limit of the math operations. Do you think we should make it work with lower bauds?
I am seeing something amiss with SD booting. It's not tied down yet.
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
Can you lengthen the timeout, at least for now. It's probably more difficult to set a com port to use and allow more time.
Currently there is no way to load if an SD card is present.
Okay. How long of a timeout do we need? 1 second?
1second would be fine.
Might it be easy to do a quick run thru the ports and if not found then repeat with a 1s timeout?
Comments
What modifications did you do to the BeMicro-A9 to work with SD?
I boot with and SD card that does not have valid files "_BOOT_P2.BIX" or "_BOOT_P2.BIY".
The boot seems to go fine, and finding that no file is present, it jumps to Chip's serial boot. So far so good.
Now I can invoke the monitor with "> "<cr> and even run a rile on the SD.
BUT, pnut (tried a couple, but the latest too), cannot find the P2 at all. Then I can open PST and do "> "<cr> and up comes the monitor fine.
FYI attached are 3 P2 files that flash leds. the filename explains which led flashes (1 sec on, 1 off). Red is on P5, blue on P7 and green on P9.
FWIW Be careful when renaming your files. Uppercase to lower case doesn't work with Windows. You need to delete the file properly and then copy a fresh one.
and no sd as there is a pullup on P59 too, so goes straight to serial
I will have to put a breakout board together tomorrow.
Shame though, I also have a DE2-115 with a SD socket but no image is available for that.
The assembler saw 'if_n' as a label, since it wasn't a valid condition, but met label-name criteria.
Thanks Chip. That explains it.
Any thoughts about why pnut cannot find the P2 while the P2 is running serial awaiting the autobaud sequence?
The board will need modification though as the card switch pills MOSI low.
Do you mean at 4800 baud? I'm looking into that right now.
Flick R2 off with a hot iron (and maybe a blob of solder) as it is never needed and will interfere with boot detection.
I think it more likely that the file being loaded and run is broken. I posted some demo files to flash pins a few posts back.
You could also try this patch in the ROM to fix that missing wz. It applies to SD1 cards, and causes an error to be reported rather than continuing.
From my reading, those were separate issues ?
This is because PNut only waits 100ms for a response. The SD boot failure may take several times that.
I made the SPI check go really fast so that we could be timely with the serial check. SD boot failure doesn't happen in 5ms, like SPI.
I would have to lengthen the timeout in PNut to accommodate SD failure. This means it would take a lot longer to find a Prop2 on all the serial ports it may need to scan.
Can you lengthen the timeout, at least for now. It's probably more difficult to set a com port to use and allow more time.
Currently there is no way to load if an SD card is present.
Just overflowed ROM by ~20 bytes when adding write to SD.
No file system in place, just raw sector address.
Within autobaud_isr, the max measurement allowed is $58E4 ('limit'). This gets multiplied by $1_0000/7 = $2492 ('baud0'). The product is $0CB2C208. The top 16 bits become the bit period in system clocks: $0CB2 = 3250. At 20MHz, that's a maximum bit period of 3250 / 20M = 162.5us = 6153 baud. That's why 4800 baud fails, it's too slow. Really, that RC oscillator can run up to 30MHz in the fast corner. That would increase the minimum baud to 6153 * (30M/20M) = 9230 baud. So, 9600 baud needs to be considered as the lower baud limit for the auto-baud detector. At the other extreme, it can go up to 2M baud in the slow corner.
So, the actual auto-baud range for the booter must be declared as 9,600 to 2,000,000 baud. I will change the Google Doc now.
Okay. How long of a timeout do we need? 1 second?
I allow around half a second for SD cards so 1 second should be fine.
I also saw that 9600 baud limit the other day but I didn't consider it a problem. Now if you can't go above 4800 baud, now that is a problem
I updated the FPGA-images-with-new-ROM file at the top of this thread and there's now a DE2-115 image. The SPI/SD pins (P61..P58) are mapped directly to the general-purpose I/O's, not the built-in SD card socket.
Is that a limit in the Smart Hardware (eg 16b Divider ?), or just a limit in the maths of a fitting the scale into a 32b result ?
It's a limit of the math operations. Do you think we should make it work with lower bauds?
No, unless you want to accommodate Heater and his Flexowriter. Will the serial loader support paper tape in EBCDIC format?
I hope it works. It should.
Just checked it on a DE2 - all good!
80MHZ
DE2 LED chaser in TAQOZ Slow it down by pressing key3
https://en.m.wikipedia.org/wiki/Modem#/media/File:Analogue_modem_-_acoustic_coupler.jpg
Might it be easy to do a quick run thru the ports and if not found then repeat with a 1s timeout?
My ears are burning. It's OK. Nice that you should think of me but sadly I don't actually have a Flexowriter.
We can make paper tape fly you know