Thanks Lachlan & Brian.
I'll see if I can reproduce this.
We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
I wonder if the same problem exists in the Flash not releasing its DO ???
BTW I have
SanDisk Ultra 64GB SDXC I U1 C10 A1 red & grey formatted exFAT
SanDisk Ultra 16GB SDHC I C10 A1
and some smaller black SanDisk 1GB, 2GB, 8GB
and some other brands including
MIXZA 8GB SDHC I U1
OV 64GB SDXC U1 C10
After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
Unfortunately, many of us have paid $150 for the current boards. It would be nice if they continued to work.
True, yet many of us paid way way more than that on FPGA boards etc and while they "continue to work", we won't need them and were happy to pay the price to have a leg in on the development and testing of the P2. I would think then that $150 was a very small price to pay. Perhaps you can sell it on eBay for twice that as a "collectors" piece.
After P2+ comes out, with only 120 chips out in the world, tools can focus exclusively on P2+. We'll have a few months of crossover time.
Unfortunately, many of us have paid $150 for the current boards. It would be nice if they continued to work.
True, yet many of us paid way way more than that on FPGA boards etc and while they "continue to work", we won't need them and were happy to pay the price to have a leg in on the development and testing of the P2. I would think then that $150 was a very small price to pay. Perhaps you can sell it on eBay for twice that as a "collectors" piece.
Addendum: The Samsung card ends up in 'serial' - so from there I can
'> ESC' to Taqoz 1 from P2ES ROM,
'> ^D' to P2 Monitor
These are reachable regardless of whether Flash is on or off.
We seem to have lost the ability to go from Taqoz 2 to Monitor 2h (control D doesn't do it)
I didn't realize it was in serial because everything looks dead (no led activity etc). Sorry!
OK. Then "> ctl-D" goes to the monitor.
Can you then try "R_BOOT_P2.BIX"<enter> to see if it will reload the boot file please?
Note there is no space between "R" and the filename (8.3) which can be any file (including not found ones). The filename is case sensitive!!
If you substitute "L" for "R" the filename will be loaded but not run, and returns to the monitor with either "=" for success or "!" for failed/not found.
For the most part the v32 instructions are a subset of the v33 instructions. If the larger offsets for the PTRx registers aren't used, and the PTRx registers aren't used for the RDLUT and WRLUT the v33 non-smartpin should encode and work the same as v32.
I think there will have to be a small change in the PTRx encoding when using a negative offset, and not incrementing or decrementing. I'm not sure how much the BITx instructions have change, but I hope they're the same if SETQ/SETQ2 is not used. It seems like it feasible to generate a v32 binary that could also run on a v33 P2.
A v32 flag can be added to the assemblers, and they could generate an error if a v33 extension is encountered. I don't see why the current P2 Eval board couldn't be supported for many years.
Thanks Lachlan & Brian.
I'll see if I can reproduce this.
We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
I wonder if the same problem exists in the Flash not releasing its DO ???
Yes it looks like the same problem of SD card not releasing P58 (MISO).
Its not the flash because we can switch its enable off so it is out of the picture
We have also sent through a dozen or two extra P60 clock transitions from Taqoz 2, but it still doesn't release the P58 pin. In fact the P58 pin seems to follow the voltage on the P60 pin as we clock it
Also we can watch with the multimeter - 'float' shows up as 1.65v in highZ mode - separate to hi 3v3 and lo 0v.
Finally, when we physically remove the card, the SO line (P58) goes to the floating voltage of 1.65v.
Thanks Lachlan & Brian.
I'll see if I can reproduce this.
We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
I wonder if the same problem exists in the Flash not releasing its DO ???
Yes it looks like the same problem of SD card not releasing P58 (MISO).
Its not the flash because we can switch its enable off so it is out of the picture
Not necessarily. This is originally what we thought with the SD, but bringing SD-CS=1 does not always release the SD from driving the DO pin.
Tho it does seem that I may still have a problem of not releasing DO properly from all exit/abort cases.
We have also sent through a dozen or two extra P60 clock transitions from Taqoz 2, but it still doesn't release the P58 pin. In fact the P58 pin seems to follow the voltage on the P60 pin as we clock it
The SD requires the clocking to be on P61, not P60. It is still weird tho. The clocking is supposed to be with SD-CS=1 tho you could try both ways.
Also we can watch with the multimeter - 'float' shows up as 1.65v in highZ mode - separate to hi 3v3 and lo 0v.
Finally, when we physically remove the card, the SO line (P58) goes to the floating voltage of 1.65v.
So it really seems that there is a lock-up problem somewhere on the SD card.
But it seems from what you are saying, it is only a problem when the Flash is invoked. Perhaps its a problem that the SD card is getting into a lockup because of accessing the Flash ???
Maybe we may not be able to get both Flash & SD to co-exist with access to both, only co-exist with either or ???
Its not just a problem with Flash, on the Samsung card not releasing MISO (DO) also prevents subsequent boot from same SD card
I think it points to SD rather than Flash, because when I physically remove the SD card, P58 goes to 'float' voltage of 1.65V. The Flash chip is still there and powered
The 'release' mechanism you tested with Sandisk - can you describe what you did to get the card to release? Was it just pulsing P61 or is there more to it?
You need cs high and then extra clocks to release the DO line. The card itself needs extra clocks after the operation but it doesn't care if cs is high or low for that part.
Toshiba 16 GB SDHC (reports as Panasonic in Taqoz) - needs 1 extra clock to release MISO
Samsung EVO+ 64 GB SDXC - needs 1 extra clock (same as Samsung EVO
Verbatim Premium 64GB microSDXC - needs 1 extra clock
SanDisk Extreme 64GB SDXC - DOES NOT RELEASE MISO - even with 40 or so clocks i tested with.
Goes to show really need to test with multiple types even within a brand.
That last one is from Officeworks (Red and Gold, instead of Red and Silver colour coding)
Ok there's another dimension to this. Some cards (SanDisk 64 GB SDXC Extreme and 16 GB Ultra SDHC) are able to boot multiple times despite not releasing the MISO line.
Other cards (Samsung EVO, EVO+, and Team) will only reboot if they have released the MISO line to floating.
Or, perhaps there is a physical pullup resistor so they show 3v3 on the MISO line, but internally the card logic has released the line.
Anyway the good news is looks like all the Sandisk variants boot multiple times without having to be physically removed from the socket, which at least gives us a "don't have to think too hard" option
...
Or, perhaps there is a physical pullup resistor so they show 3v3 on the MISO line, but internally the card logic has released the line.
Could be, that's why the idea of a two-resistor biased level for testing is a good one. eg choose R's to bias 2.7~3.0V region. = Hi, but not at rail.
You can see CMOS drive in both directions, and Float and also pullups too, on a scope.
The Team card doesn't need 2, it only needs 1 additional pulse, then it can reboot OK, even though MISO is not floating.
Perhaps its just the extra pulse thats works enough magic to cover all cases.
Sorry for the twists and turns in this reporting. Its now looking like just adding that extra single pulse might be enough.
Not at all. Thanks for your great help in tracking this down
There just wasn't enough time because I had forgotten about this problem.
Attached is v003d. You will require a small pulldown on P58 for this test to work. I have 15K.
Hopefully this should fix all your cards. It debugs what DO was and is after the extra clocks. They are in one subroutine "check_DO".
Currently I am sending 8*2 clocks which means 8 clocks. Just change the REP statement if you find you need more.
If we submit another ROM, we may get charged another $2500. We just had a conference call today about all this and I agreed there'd be no more changes. We're probably going to have to live with what ROM we've got.
Just the same, might as well perfect it for future chances to submit a new ROM.
I did get some layout changes made to the PLL loop filter which should improve the PLL performance quite a bit.
If we submit another ROM, we may get charged another $2500. We just had a conference call today about all this and I agreed there'd be no more changes. We're probably going to have to live with what ROM we've got.
Just the same, might as well perfect it for future chances to submit a new ROM.
I did get some layout changes made to the PLL loop filter which should improve the PLL performance quite a bit.
That's fine Chip.
I need to fully understand the problem and then I will get it fixed just in case there is another reason for a change.
Great news about the PLL as that's been bothering me because of the jitter I had seen. Hopefully it will fix a few things we've seen.
There is a lot of debug information output. In particular, the SD-DO is tested and reported. The first value (typically 1) is before I send 8 clocks and the second value (should be 0) is after the clocks. If the second is not 0, then it will be followed by *****. Please let me know if you find any of these.
Oh, and you'll need a 10K+ pulldown on P58 for my testing.
Hopefully I've nailed the DO release problem. Also, I've done some code rework including booting from exFAT formatted SD cards - yes it can find a file named as 8.3 in the root directory and load/run it. I removed code which was not of any use, such as reading the CSD, CID, FSI sector and FAT sector. And I am certain I've not violated any MS purported patents. Writing files to the card may be a different matter tho.
Beware, the format must be 8.3. In exFAT the decimal is included in the filename and I require the decimal to be in the 9th character position!!! This is not a problem for booting since the ROM will be hard-coded to "_BOOT_P2.BIX" and "_BOOT_P2.BIY".
There is no guarantee this will make it into the silicon, or will fit either, but I'll be ready just in case
Comments
I'll see if I can reproduce this.
We found that the SD card (old ROM) was not releasing the DO pin. Hopefully I fixed this in the new ROM (should be in 0002h).
I wonder if the same problem exists in the Flash not releasing its DO ???
BTW I have
SanDisk Ultra 64GB SDXC I U1 C10 A1 red & grey formatted exFAT
SanDisk Ultra 16GB SDHC I C10 A1
and some smaller black SanDisk 1GB, 2GB, 8GB
and some other brands including
MIXZA 8GB SDHC I U1
OV 64GB SDXC U1 C10
'> ESC' to Taqoz 1 from P2ES ROM,
'> ^D' to P2 Monitor
These are reachable regardless of whether Flash is on or off.
We seem to have lost the ability to go from Taqoz 2 to Monitor 2h (control D doesn't do it)
I didn't realize it was in serial because everything looks dead (no led activity etc). Sorry!
True, yet many of us paid way way more than that on FPGA boards etc and while they "continue to work", we won't need them and were happy to pay the price to have a leg in on the development and testing of the P2. I would think then that $150 was a very small price to pay. Perhaps you can sell it on eBay for twice that as a "collectors" piece.
OK. Then "> ctl-D" goes to the monitor.
Can you then try "R_BOOT_P2.BIX"<enter> to see if it will reload the boot file please?
Note there is no space between "R" and the filename (8.3) which can be any file (including not found ones). The filename is case sensitive!!
If you substitute "L" for "R" the filename will be loaded but not run, and returns to the monitor with either "=" for success or "!" for failed/not found.
I think there will have to be a small change in the PTRx encoding when using a negative offset, and not incrementing or decrementing. I'm not sure how much the BITx instructions have change, but I hope they're the same if SETQ/SETQ2 is not used. It seems like it feasible to generate a v32 binary that could also run on a v33 P2.
A v32 flag can be added to the assemblers, and they could generate an error if a v33 extension is encountered. I don't see why the current P2 Eval board couldn't be supported for many years.
Yes it looks like the same problem of SD card not releasing P58 (MISO).
Its not the flash because we can switch its enable off so it is out of the picture
We have also sent through a dozen or two extra P60 clock transitions from Taqoz 2, but it still doesn't release the P58 pin. In fact the P58 pin seems to follow the voltage on the P60 pin as we clock it
Also we can watch with the multimeter - 'float' shows up as 1.65v in highZ mode - separate to hi 3v3 and lo 0v.
Finally, when we physically remove the card, the SO line (P58) goes to the floating voltage of 1.65v.
Tho it does seem that I may still have a problem of not releasing DO properly from all exit/abort cases. The SD requires the clocking to be on P61, not P60. It is still weird tho. The clocking is supposed to be with SD-CS=1 tho you could try both ways. So it really seems that there is a lock-up problem somewhere on the SD card.
But it seems from what you are saying, it is only a problem when the Flash is invoked. Perhaps its a problem that the SD card is getting into a lockup because of accessing the Flash ???
Maybe we may not be able to get both Flash & SD to co-exist with access to both, only co-exist with either or ???
I think it points to SD rather than Flash, because when I physically remove the SD card, P58 goes to 'float' voltage of 1.65V. The Flash chip is still there and powered
The 'release' mechanism you tested with Sandisk - can you describe what you did to get the card to release? Was it just pulsing P61 or is there more to it?
'+-----------------------------------------------------------------------------+ \ {{ tweek }} '+ /CS=1, Release SD Card DO pin, tristate SD CS/CK/DI/DO + | '+-----------------------------------------------------------------------------+ | _releaseDO outh #sd_cs ' /CS=1 | call #@_sendFF ' 8 CLKs | andn dirb, ##($F<<26) ' tristate CS/CK/DI/DO | ret wcz ' restore flags | '+=============================================================================+ / '+-----------------------------------------------------------------------------+ '+ SD SPI Send/Recv Routines... (write/read byte/long simultaneously) + '+ /CS=0 & CLK=0 on both entry and exit + '+-----------------------------------------------------------------------------+ _recvlong neg dataout, #1 ' call here to Recv a Long (+send 1's) _sendlong mov bitscnt, #32 ' call here to Send a Long (long=32bits) jmp #@_sendrecv ' _sendFF ' call here to Send $FF Byte _recvbyte neg dataout, #1 ' call here to Recv a Byte (+send 1's) _sendbyte rol dataout, #24 ' call here to Send a Byte (msbit first) mov bitscnt, #8 ' (byte=8bits) _sendrecv mov reply, #0 ' clear reply ' 8+15 low/high clk cycles (8.7MHz@200MHz, 1.3MHz@30MHz) .nextbit rol dataout, #1 wc ' \ prepare output bit (DI=0/1).. outl #sd_ck ' | CLK=0 (already 0 first time) outc #sd_di ' / write output bit: output on CLK falling edge waitx #2 ' | setup time to be safe outh #sd_ck ' \ CLK=1 waitx #3 ' | setup time to be safe testp #sd_do wc ' | read input bit: sample on CLK rising edge rcl reply, #1 ' / accum DO input bits djnz bitscnt, #.nextbit ' 8/32 bits? _RET_ outl #sd_ck ' CLK=0 on exit '+=============================================================================+Toshiba 16 GB SDHC (reports as Panasonic in Taqoz) - needs 1 extra clock to release MISO
Samsung EVO+ 64 GB SDXC - needs 1 extra clock (same as Samsung EVO
Verbatim Premium 64GB microSDXC - needs 1 extra clock
SanDisk Extreme 64GB SDXC - DOES NOT RELEASE MISO - even with 40 or so clocks i tested with.
Goes to show really need to test with multiple types even within a brand.
That last one is from Officeworks (Red and Gold, instead of Red and Silver colour coding)
Other cards (Samsung EVO, EVO+, and Team) will only reboot if they have released the MISO line to floating.
Or, perhaps there is a physical pullup resistor so they show 3v3 on the MISO line, but internally the card logic has released the line.
Anyway the good news is looks like all the Sandisk variants boot multiple times without having to be physically removed from the socket, which at least gives us a "don't have to think too hard" option
Perhaps its just the extra pulse thats works enough magic to cover all cases.
Sorry for the twists and turns in this reporting. Its now looking like just adding that extra single pulse might be enough.
Could be, that's why the idea of a two-resistor biased level for testing is a good one. eg choose R's to bias 2.7~3.0V region. = Hi, but not at rail.
You can see CMOS drive in both directions, and Float and also pullups too, on a scope.
Not at all. Thanks for your great help in tracking this down
There just wasn't enough time because I had forgotten about this problem.
Attached is v003d. You will require a small pulldown on P58 for this test to work. I have 15K.
Hopefully this should fix all your cards. It debugs what DO was and is after the extra clocks. They are in one subroutine "check_DO".
Currently I am sending 8*2 clocks which means 8 clocks. Just change the REP statement if you find you need more.
Just the same, might as well perfect it for future chances to submit a new ROM.
I did get some layout changes made to the PLL loop filter which should improve the PLL performance quite a bit.
What do you work on next, Spin2 interpreter?
That's fine Chip.
I need to fully understand the problem and then I will get it fixed just in case there is another reason for a change.
Great news about the PLL as that's been bothering me because of the jitter I had seen. Hopefully it will fix a few things we've seen.
Yes and yes.
(In trying to respond to your post, I accidentally edited it, though it's unchanged.)
Have to draw the line in the sand sometime. There will always be one more thing.
There is a lot of debug information output. In particular, the SD-DO is tested and reported. The first value (typically 1) is before I send 8 clocks and the second value (should be 0) is after the clocks. If the second is not 0, then it will be followed by *****. Please let me know if you find any of these.
Oh, and you'll need a 10K+ pulldown on P58 for my testing.
Hopefully I've nailed the DO release problem. Also, I've done some code rework including booting from exFAT formatted SD cards - yes it can find a file named as 8.3 in the root directory and load/run it. I removed code which was not of any use, such as reading the CSD, CID, FSI sector and FAT sector. And I am certain I've not violated any MS purported patents. Writing files to the card may be a different matter tho.
Beware, the format must be 8.3. In exFAT the decimal is included in the filename and I require the decimal to be in the 9th character position!!! This is not a problem for booting since the ROM will be hard-coded to "_BOOT_P2.BIX" and "_BOOT_P2.BIY".
There is no guarantee this will make it into the silicon, or will fit either, but I'll be ready just in case
https://www10.edacafe.com/nbc/articles/1/1651612/Micron-Unveils-Worlds-First-1TB-microSD-Card-Meet-Consumer-Demand-Mobile-Storage
https://www.micron.com/products/memory-cards/consumer-microsd-cards
Wonder what happens then, and can we boot from whatever comes next?