Took me 1.5 years to get it going. Can't quite fathom how that happened.
But then, Tony and I spent even longer on the XORO32 analysis. We started on that before 2017 I think. I remember that date because I upgraded from a dual-core PC to 8-core early in 2017. It was fun making use of that many cores in parallel for the first time.
@evanh said:
Took me 1.5 years to get it going. Can't quite fathom how that happened.
But then, Tony and I spent even longer on the XORO32 analysis. We started on that before 2017 I think. I remember that date because I upgraded from a dual-core PC to 8-core early in 2017. It was fun making use of that many cores in parallel for the first time.
I joined this forum by chance in April 2017 as TonyB. I forgot my password a couple of months later but my free email service had been shut down so I've been TonyB_ ever since. I can't believe it's been eight years.
Any memory the events of that chance? For me, it was a post on the Pixaxe forum by another user saying the Propeller had 8 cores. I immediately wanted to look at the architecture.
Have you tried the FlexProp uSD driver with it?
The ones here, supposedly identical, have this strange thing where need to run FSRW before the FlexProp uSD interface works...
Internal error ain't too helpful an error message.
PS: Here's verbose output from LoadP2. It doesn't appear anything is wrong but the EEPROM doesn't get programmed. EDIT2: Or at least it isn't booting upon reset ...
$ loadp2 eeprom_check.binary -p /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4001xIP-if00-port0 -t -b 2000000 -FLASH -v
trying /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4001xIP-if00-port0...
P2 version G found on serial port /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4001xIP-if00-port0
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader...
address=0x000fc000 size=2ac
device response to header: `s'
chksum: 3a OK
Loading eeprom_check.binary - 60180 bytes
address=0x00000000 size=eb14
device response to header: `s'
chksum: 6b OK
highest hub address: 0xeb14 chksum: 0xea4c1b84
address=0x80000000 size=400
device response to header: `k'
Sending blocks: .chksum: 8f OK
sending F 0x0000eb14 to device
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 200000000 clkmode = 0x10009fb
Compiled with FlexC v7.4.1-beta-v7.4.0-3-gd3cadbe0
...
Yep, just worked out I need to add a pull-up to P61. The ROM doesn't attempt booting EEPROM without that ... There is a pull-up on the other side of U1 logic gate but that's completely of no use there as far as I can see ...
Hmm, actually, P61 needs to be a bidirectional signal. It needs a real switch really ... or an analogue mux/switching chip. The old CMOS 4066 did that, there will be modern single gate LVC parts around ...
PS: I have the Swap module booting from EEPROM now, so Loadp2 was working fine all along.
PPS: SD card not appearing to respond at this stage.
Not doing that!!! There's gotta be a proper fix. It's not the only oddity either. I think I've bumped into same problem Ada had with a Sandisk card reporting incorrect type info too ... only happens in the Swap module though ...
@evanh said:
I think I've bumped into same problem Ada had with a Sandisk card reporting incorrect type info too
Oh that one, I think I forgot to ever follow up on that problem...
I got that wrong. The behaviour is different to what you had, and I found it happens to all cards. The Sandisk was just the first because it was the first card I was experimenting with.
What's happening is the SD card is readable after booting from serial ... and continues to be readable through successive reboots from EEPROM until the SD card is powered cycled. Once the SD card is power cycled the booting from EEPROM behaviour changes to SD card having no response to the repeating ACMD41 loop after a successful CMD8 SDv2 response.
It seems backwards in that a power cycle is usually considered advantageous for resetting SD cards but I've rechecked the behaviour many times now.
Arrg! Still didn't check enough it seems. It's got different along the way. I now realise the Swap module behaviour has changed with my software edits since I started. The original Sandisk (32G) is still different. It no longer responds to ACMD41 at all. Power cycled or not.
BTW, card init takes over 8 minutes to fail in these cases. (1000 x 500 ms timeout)
It has to be a driver init issue. I'll get the scope out and see if anything shows up there ... It's easily repeatable for me at least. I've now got a case that happens even without the EEPROM involved.
EDIT: Maybe I need more pull-ups still. P57 should have one to ensure the RTC doesn't interfere ... Oops, I'm pulsing P57 for debug. That was safe on the Eval board of course. Time to throw that away ....
Ah, that was it, the RTC must have locked the data pins. All working now, EEPROM boots then mounts and loads a file from the SD card. Works every time from cold power up with all five cards tested so far.
Okay, so I'm using a modified add-on driver right now. I'll see if I can duplicate your internal driver conditions Rayman ...
I note you were toggle pins P58/P59, is that still the case? https://forums.parallax.com/discussion/comment/1567376/#Comment_1567376
The driver only configures the serial smartpins once at init time. After that it just assumes the pins stay configured. If the serial input pin was later set high by the user program then it'd definitely interfere with the SD driver.
Well, I'm having no issues now that I've fixed my own pin toggling interference - and added those four extra pull-ups that were missing in the earlier Swap modules. Flexspin's built-in filesystem abilities seem fine with the Swap's SD slot.
Give this a whirl. It reports progress in terminal. I use Loadp2 to both program the EEPROM and as the terminal. I power cycle the Swap module without quitting the terminal so then I can see it repeat a cold boot.
PS: Copy a file (> 4kB) to the SD card first. Name it EEPROM.BIN
Comments
Took me 1.5 years to get it going. Can't quite fathom how that happened.
But then, Tony and I spent even longer on the XORO32 analysis. We started on that before 2017 I think. I remember that date because I upgraded from a dual-core PC to 8-core early in 2017. It was fun making use of that many cores in parallel for the first time.
I joined this forum by chance in April 2017 as TonyB. I forgot my password a couple of months later but my free email service had been shut down so I've been TonyB_ ever since. I can't believe it's been eight years.
Any memory the events of that chance? For me, it was a post on the Pixaxe forum by another user saying the Propeller had 8 cores. I immediately wanted to look at the architecture.
@evanh Don't you have one of these modules?
Have you tried the FlexProp uSD driver with it?
The ones here, supposedly identical, have this strange thing where need to run FSRW before the FlexProp uSD interface works...
Wondering if you see the same thing...
I'm not at home right now so can't test anything but yep I do have an original Knivd built module.
I've not booted the SD with it though. I assume that's part of the process here. Or does this behaviour happen with serial boot too?
Booting from flash and then trying to access uSD…
Got it. And this is specifically MegaYume by the sounds of it.
Think it’s anything using Flexprop driver
Made a website for it: https://www.rayslogic.com/Store/SWaP/P2SWaP.html
Guess that counts as progress...
There are some things with the uSD and RTC code that need work, but think the hardware is good.
@knivd gave permission to post design files. So, can be "open hardware".
In principle, anybody can take the Gerbers and have their own modules made...
Huh, I can't get the EEPROM written at all. It stays blank every attempt. Loadp2 doesn't seem to sequence it correctly.
EDIT: Attempting to use PropLoader produces this:
Internal error ain't too helpful an error message.
PS: Here's verbose output from LoadP2. It doesn't appear anything is wrong but the EEPROM doesn't get programmed. EDIT2: Or at least it isn't booting upon reset ...
Ok, that is not good.
Heard about a problem flashing binary with loadp2 and need to use proploader but this sounds like an actual hardware failure…
But this module has some logic chips to turn various things off. Maybe a problem there?
Yep, just worked out I need to add a pull-up to P61. The ROM doesn't attempt booting EEPROM without that ... There is a pull-up on the other side of U1 logic gate but that's completely of no use there as far as I can see ...
I presume you've added a pull-up yourself?
Hmm, actually, P61 needs to be a bidirectional signal. It needs a real switch really ... or an analogue mux/switching chip. The old CMOS 4066 did that, there will be modern single gate LVC parts around ...
PS: I have the Swap module booting from EEPROM now, so Loadp2 was working fine all along.
PPS: SD card not appearing to respond at this stage.
Schematic shows a pull-up on p61.
Maybe yours is earlier revision …
My schematic must be older too. Bottom right corner says "P2-STAMP (C) Kn/vD"
It's weird. Even when serial booting, somehow that's preventing the SD card being accessed. When I remove P61 pull-up I can read the SD card.
Hmm…. Try reading with fsrw
That works for me. After that FatFs works.
Not doing that!!! There's gotta be a proper fix. It's not the only oddity either. I think I've bumped into same problem Ada had with a Sandisk card reporting incorrect type info too ... only happens in the Swap module though ...
Oh that one, I think I forgot to ever follow up on that problem...
I got that wrong. The behaviour is different to what you had, and I found it happens to all cards. The Sandisk was just the first because it was the first card I was experimenting with.
What's happening is the SD card is readable after booting from serial ... and continues to be readable through successive reboots from EEPROM until the SD card is powered cycled. Once the SD card is power cycled the booting from EEPROM behaviour changes to SD card having no response to the repeating ACMD41 loop after a successful CMD8 SDv2 response.
It seems backwards in that a power cycle is usually considered advantageous for resetting SD cards but I've rechecked the behaviour many times now.
Arrg! Still didn't check enough it seems. It's got different along the way.
I now realise the Swap module behaviour has changed with my software edits since I started. The original Sandisk (32G) is still different. It no longer responds to ACMD41 at all. Power cycled or not.
BTW, card init takes over 8 minutes to fail in these cases. (1000 x 500 ms timeout)
@evanh Whatever is going wrong with FatFS and SWaP, FSRW seems to fix it.
It has to be a driver init issue. I'll get the scope out and see if anything shows up there ... It's easily repeatable for me at least. I've now got a case that happens even without the EEPROM involved.
EDIT: Maybe I need more pull-ups still. P57 should have one to ensure the RTC doesn't interfere ... Oops, I'm pulsing P57 for debug. That was safe on the Eval board of course. Time to throw that away ....
Ah, that was it, the RTC must have locked the data pins. All working now, EEPROM boots then mounts and loads a file from the SD card. Works every time from cold power up with all five cards tested so far.
Okay, so I'm using a modified add-on driver right now. I'll see if I can duplicate your internal driver conditions Rayman ...
Switching to the built-in driver is no issue.
I note you were toggle pins P58/P59, is that still the case? https://forums.parallax.com/discussion/comment/1567376/#Comment_1567376
The driver only configures the serial smartpins once at init time. After that it just assumes the pins stay configured. If the serial input pin was later set high by the user program then it'd definitely interfere with the SD driver.
@evanh did think pin toggling was the problem but it wasn’t …
Well, I'm having no issues now that I've fixed my own pin toggling interference - and added those four extra pull-ups that were missing in the earlier Swap modules. Flexspin's built-in filesystem abilities seem fine with the Swap's SD slot.
Problem might be that FatFs only tries once to mount?
Fsrw tries several times. Doesn’t always work the first time…
Do your pull-ups match the revd schematic?
Give this a whirl. It reports progress in terminal. I use Loadp2 to both program the EEPROM and as the terminal. I power cycle the Swap module without quitting the terminal so then I can see it repeat a cold boot.
PS: Copy a file (> 4kB) to the SD card first. Name it EEPROM.BIN
4k7 on P57,P58
10k on P46,P61