Trouble loading a "custom xmm" SD-card system
denominator
Posts: 242
Not owning an XMM-capable Propeller, tonight I set out to make one. I added a Parallax-standard micro-sd card reader to my demo board, connecting pins DO=7, CLK = 5, DI = 6, CS=4. Thinking that this should exactly mimic the "morpheus" system in propeller-load.cfg, I went on to make a test.
I created a simple program that performs some floating point calculations and prints them, and compiled it thusly:
The total size is: 36K, firmly in XMM (vs LMM) land.
I then tried to load my system like this:
However, in an XMM program, the text segment has a load address at 0x3000000, and the kernel has a load address at 0x8000000. Therefore, GetProgramSize() returns a huge number, something like 0x800006bc.
Note that I ran into this trouble with both the 0.2.2 and 0.2.3 release.
Because other folks have loaded XMM programs, I'm assuming that either (1) I don't understand what's going on in the loader or (2) I really messed up my compile or propeller-load command line arguments. I can't rule out another choice: (3) both.
Should I be able to run XMM programs on a Demo Board + SD card system? Can somebody tell me what I did wrong?
I created a simple program that performs some floating point calculations and prints them, and compiled it thusly:
propeller-elf-gcc -Os -mxmmc -mfcache -o main.o -c main.c propeller-elf-gcc -mxmmc -o main.elf main.o -lm
The total size is: 36K, firmly in XMM (vs LMM) land.
I then tried to load my system like this:
propeller-load -p 3 -b morpheus -z -r -t main.elf Propeller Version 1 on COM3 error: insufficient memory error: load failedThe "insufficient memory" looked pretty nebulous (there are many places in the loader that print this error), so I modified the propeller-load code to print out who ran out of memory; it was the malloc() in BuildInternalImage. I then looked at the code in GetProgramSize() that calculates the size that BuildInternalImage tries to allocate. It appears that GetProgramSize scans all the program segments, looking for both the lowest start address of all segments and also the highest end address of all segments. It then subtracts the two, assuming that's the program's size.
However, in an XMM program, the text segment has a load address at 0x3000000, and the kernel has a load address at 0x8000000. Therefore, GetProgramSize() returns a huge number, something like 0x800006bc.
Note that I ran into this trouble with both the 0.2.2 and 0.2.3 release.
Because other folks have loaded XMM programs, I'm assuming that either (1) I don't understand what's going on in the loader or (2) I really messed up my compile or propeller-load command line arguments. I can't rule out another choice: (3) both.
Should I be able to run XMM programs on a Demo Board + SD card system? Can somebody tell me what I did wrong?
Comments
OK, I think it's number 3. I neglected to see in the instructions that you don't put the "main.elf" on the propeller-load line. (I missed it because it was in a separate part of my Makefile, and I didn't even consider removing it). After removing it, the "insufficient memory" errors went away and the loader started loading my demoboard!
I must say that I'm generally confused by the propeller-load wiki and I've only recently been able to start making a mental model to sort things out, but only after re-reading it several times. I think there are some typos, some too-similar terms ("twisty little passage ways, all different"), and maybe a few inconsistencies in the comments in the actual driver code that are tripping me up. Not a complaint, just an observation...
I'm stuck now on two problems:
1) propeller-load often gives a "Verifying... Upload Timeout Error!". I've been working around this by re-running the upload.
2) When it does run, I get:
Then nothing; it just hangs. Note that I did run propeller-load -x main.elf to get the .pex file, and I installed it on my SD card as AUTORUN.PEX. I tried two different 4GB SDHC cards (Kingston and Transcend). Both just hang. I know the driver is trying to do something, because if I remove the SD card, I get:
A stab in the dark: I read that micro-SD cards are not obligated to support SPI mode, but that many/most do. Another forum post seemed to indicate that non-SPI micro-SD cards are rare (see http://forums.parallax.com/showthread.php?118628-micro-SD.-are-serial-resisters-important/page2 ). Does the cache driver recognize this and spit out the appropriate error?
Note that I'm using the Parallax micro-SD card adapter, and it's got the required pull-up resistors. And I have the card connected to the demo board using very short wires.
Does anybody have any help on this one, or do I dive into debugging the sd_driver.spin program?
On the reload propeller-load problem, i think that removing a line in propgcc/loader/src/PLoadLib.c may help.
Around line 129 there is a msleep(50) ... I have that commented out. You might try that too.
/** * hwfind ... find propeller using sync-up sequence. * @param hSerial - file handle to serial port * @returns zero on failure */ static int hwfind(void) { int n, ii, jj, rc, to; uint8_t mybuf[300]; //msleep(50); // pause after reset - 100ms is too long mybuf[0] = 0xF9; LFSR = 'P'; // P is for Propeller :)One thing about the SDcard cache driver and filesystem today is that it only works with 2GB cards.
This is a problem AFAIC, and needs to be fixed. One of the target PropBOE modes is SDCard XMMC.
That code fix makes it rock-solid for me, Thanks!. The funny thing is that I only saw that error with my Demoboard (where it happens 60% of the time); I don't remember seeing the "Upload Timeout Error" on the Professional Demo board nor any of several SpinStamps through very many loads.
One thing that occurs to me is that it might be good to have the -z option allow a filename and then use that as the name of the file to load off of the SD card. Does that make sense?