New XMM hardware

Dr_Acula · 2012-04-29 05:12

Thanks jazzed.

I guess I'm right on the cutting edge of the alpha testing now

It works better. The build dialog says it is "outloading the serial helper"
Then 9528 bytes sent
Then verifying ram, loading a.pex to sd card
Then a pause, and then "timeout waiting for ack/nak"

David Betz · 2012-04-29 05:18

Dr_Acula wrote: »

Thanks jazzed.

I guess I'm right on the cutting edge of the alpha testing now

It works better. The build dialog says it is "outloading the serial helper"
Then 9528 bytes sent
Then verifying ram, loading a.pex to sd card
Then a pause, and then "timeout waiting for ack/nak"

What board are you using for this test? I had this running on a DracBlade. We even include a dracblade.cfg file with PropGCC. One thing that can cause ack/nak problems is having the clock parameters set wrong. Have you checked that?

Dr_Acula · 2012-04-29 05:51

I'm testing with two boards.Same error with both.
Board one is the Dracblade SDXMMC
Board two has the SD card on different pins

I can stick with the dracblade if you like, then it is exactly the same as what you have. I presume you have v 0.6.8 of the IDE?

What are the clock parameters?

David Betz · 2012-04-29 06:43

Dr_Acula wrote: »

I'm testing with two boards.Same error with both.
Board one is the Dracblade SDXMMC
Board two has the SD card on different pins

I can stick with the dracblade if you like, then it is exactly the same as what you have. I presume you have v 0.6.8 of the IDE?

What are the clock parameters?

This is the configuration file for DracBlade. Unfortunately, I am busy for the rest of the day so I won't be able to do any testing until tomorrow at the earliest. Sorry!

# [dracblade]
# IDE:SDLOAD
# IDE:SDXMMC
    clkfreq: 80000000
    clkmode: XTAL1+PLL16X
    baudrate: 115200
    rxpin: 31
    txpin: 30
    tvpin: 12   # only used if TV_DEBUG is defined
    cache-driver: dracblade_cache.dat
    cache-size: 8K
    cache-param1: 0
    cache-param2: 0
    sd-driver: sd_driver.dat
    sdspi-do: 12
    sdspi-clk: 13
    sdspi-di: 14
    sdspi-cs: 15
    load-target: ram

I have been using the command line compiler tools. I don't usually use SimpleIDE. Sorry!

jazzed · 2012-04-29 07:45

Dr_Acula wrote: »

Thanks jazzed.

I guess I'm right on the cutting edge of the alpha testing now

In some ways

The SD card features in the loader have been working for a while though.
As far as I can tell the feature is complete. More testing is always appreciated of course.

Dr_Acula wrote: »

It works better. The build dialog says it is "outloading the serial helper"
Then 9528 bytes sent
Then verifying ram, loading a.pex to sd card
Then a pause, and then "timeout waiting for ack/nak"

I've seen this timeout happen if the pins are not properly connected, the SD Card is not formatted, or the SD Card has errors.

I recommend reformatting the SD Card after saving any data. Either 2G or 4G+ cards work for me.

The IDE uses propeller-load for all loader operations except terminal - it also manages the SD Card downloads.
David wrote the loader - that's why he's being so helpful.

denominator · 2012-04-29 08:17

jazzed wrote: »

I've seen this timeout happen if the pins are not properly connected, the SD Card is not formatted, or the SD Card has errors.

Or if you forget to put the SD card in the reader. I also have one reader that has flakey connections; I sometimes need to remove the card and reinsert it.

Dr_Acula · 2012-04-29 16:19

Thanks for all those suggestions. The SD card is 2GB and I believe it is all correct because I have the Spin touchscreen program running on the same board and that uses the SD card many times to load icons and fonts and the like. I can reload that program from the proptool with no problems so that is a quick way to test that the SD card has not been corrupted or become loose etc.

Differences:
1) Timing. Are there any timing variables associated with that nak/ack and where would they be found?
2) The SD driver. The touchscreen code is built around Kye's SD driver and I've not used any other drivers so there is always a chance that if GCC is using another driver, the SD card I have is working with Kye's driver but not the GCC driver. Is there a simple test program one could run via LMM to test the SD card using the GCC drivers?
3) Is there a way to get inside the loader code and debug it from within? eg, with a Nak/Ack problem, is this using an xmodem type protocol where it keeps trying multiple times until it gives up?

David Betz · 2012-04-29 18:26

Dr_Acula wrote: »

Thanks for all those suggestions. The SD card is 2GB and I believe it is all correct because I have the Spin touchscreen program running on the same board and that uses the SD card many times to load icons and fonts and the like. I can reload that program from the proptool with no problems so that is a quick way to test that the SD card has not been corrupted or become loose etc.

Differences:
1) Timing. Are there any timing variables associated with that nak/ack and where would they be found?
2) The SD driver. The touchscreen code is built around Kye's SD driver and I've not used any other drivers so there is always a chance that if GCC is using another driver, the SD card I have is working with Kye's driver but not the GCC driver. Is there a simple test program one could run via LMM to test the SD card using the GCC drivers?
3) Is there a way to get inside the loader code and debug it from within? eg, with a Nak/Ack problem, is this using an xmodem type protocol where it keeps trying multiple times until it gives up?

I have you checked to make sure that the clock settings are right in the .cfg file you're using. That will certainly mess up the serial communications with the helper program. Maybe you could post your modified .cfg file?

Dr_Acula · 2012-04-29 18:34

No the clock settings have not been changed. On the first one I changed the propboe config file and added two to each of the SD card pins.

However, for the dracblade board, the cfg has not been modified at all.

What is the program that is saying it can't nak/ack? Has it already downloaded one program and it is this new program trying to establish a comms link?

If so, in that program, has it got to the stage of trying to open the sd card? Or does it establish the comms link first?

David Betz · 2012-04-29 18:41

Okay, I just tried this on my DracBlade and I can't get it to work either. It isn't the clock parameters as I suggested in an earlier message because I can do normal xmmc downloads successfully and those require a working serial connection. Here is what I get if I try to load ebasic.elf to the SD card on my DracBlade. Is this what you are seeing?

david-betzs-macbook-pro:ebasic dbetz$ propeller-load -b dracblade -z ebasic.elf -r
Propeller Version 1 on /dev/cu.usbserial
Loading the serial helper to hub memory
9528 bytes sent                  
Verifying RAM ... OK
Loading 'ebasic.pex' to SD card
Timeout waiting for ACK/NAK       
error: SendPacket DATA failed
error: load failed

David Betz · 2012-04-29 18:51

Uh, forget what I just posted. I get much further with DracBlade and ebasic.elf but it still isn't running. Here is my load transcript. It gets all the way through writing the .pex file to the SD card and loading the kernel and cache driver and trying to start the program but for some reason I don't get the Basic startup banner.

david-betzs-macbook-pro:ebasic dbetz$ propeller-load -b dracblade -z ebasic.elf -r -t
Propeller Version 1 on /dev/cu.usbserial
Loading the serial helper to hub memory
9528 bytes sent                  
Verifying RAM ... OK
Loading 'ebasic.pex' to SD card
73164 bytes sent                  
Loading sd_cache_loader.elf to hub memory
14828 bytes sent                  
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Loading cache driver
Initializing SD card
Mounting SD filesystem
Opening AUTORUN.PEX
Loading kernel
Loading cluster map
Initializing cache
Starting program

David Betz · 2012-04-29 18:55

I think my DracBlade card is flaky. Maybe I did a poor job of assembling it or something. At least half the time the loader can't even see the Propeller chip. Now I can't get it to load fibo.elf onto the SD card at all even though I got it to load ebasic.elf a while ago and that is a much bigger program.

David Betz · 2012-04-29 19:02

I think my problem was a trashed SD card filesystem. I put the card into my Mac and it said it was unreadable. I reformatted the card and tried ebasic.elf again and now it works.

david-betzs-macbook-pro:ebasic dbetz$ propeller-load -b dracblade -z ebasic.elf -r -t
Propeller Version 1 on /dev/cu.usbserial
Loading the serial helper to hub memory
9528 bytes sent                  
Verifying RAM ... OK
Loading 'ebasic.pex' to SD card
73164 bytes sent                  
Loading sd_cache_loader.elf to hub memory
14828 bytes sent                  
Verifying RAM ... OK
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Loading cache driver
Initializing SD card
Mounting SD filesystem
Opening AUTORUN.PEX
Loading kernel
Loading cluster map
Initializing cache
Starting program
ebasic 0.001
10 print "Hello"
run
H:0 O:2 D:48 V:0 T:56
Hello
OK

Dr_Acula · 2012-04-29 19:08

Ah, trashed SD cards. I've had that one in the past. I tried several clean reformatted cards but no improvement.

I'm stuck back at your post #41.

Is this what you are seeing?

Yes, exactly that.

David Betz · 2012-04-29 19:13

Dr_Acula wrote: »

Ah, trashed SD cards. I've had that one in the past. I tried several clean reformatted cards but no improvement.

I'm stuck back at your post #41.

Yes, exactly that.

My DracBlade is very flaky. The loader often doesn't see the Propeller chip at all. My board is v5. Are there any known problems with that version?

Dr_Acula · 2012-04-29 19:50

It shouldn't be flaky - I've not had any issues with the boards. I have had issues though with some of the USB to serial adaptors. The proptool changed about 3 years ago and since that change, many adaptors don't work. I'm pretty sure it is a timing issue with the reset pulses, but I couldn't get a response from parallax on that one so I gave up and bought an adaptor that has the FT232 chip inside it.

I've used xmodem to do file transfers and the debugging process is always complicated. I kind of like xmodem as it was designed for flaky phone lines, so it can handle the odd packet that goes astray.

If you have a board that is flaky, let's change to another board. The problem you posted in #41 is exactly the same on a completely different board with the sd card on different pins. What is that download program doing first - mounting/opening a file on the sd card, or establishing a link?

That will help determine where the problem is.

jazzed · 2012-04-29 19:55

Dr_Acula wrote: »

I'm stuck back at your post #41.

Can you do an experiment? The idea is to see if the boot-loader can read your SD card.

Set Memory Model to XMMC
Set the board type to DRACBLADE (no -SDXMMC)
Click the Burn F11 button to build and save bootloader to eeprom.
Using windows explorer copy the a.pex file to AUTORUN.PEX on your SD Card
Insert SD Card into your board
Open terminal window
Press reset
Copy result from the terminal to here

Thanks.
--Steve

jazzed · 2012-04-29 20:08

Oops. Change of plan.

In step 2, you must use DRACBLADE-SDXMMC
It's OK of step 2 fails for now. The point is to get the loader burned into EEPROM.

Thanks.

denominator · 2012-04-29 20:57

Dr_Acula wrote: »

Is there a simple test program one could run via LMM to test the SD card using the GCC drivers?

Indeed there is. Go to the demos/c3files demo. Edit demos/c3files/src/filetest.c, locate the mount() routine within it to set up a config that's valid for your board. Then go to demos/c3files/lmm directory and run make. Then use propeller-load to send this program to your board and run it - it will test the GCC SD routines.

The above instructions assume you're running the command line tools. It should be easy to put the files in the demos/c3files/src into a SimpleIDE project if that's how you roll.

Dr_Acula · 2012-04-29 21:19

Thanks everyone, I'll do this when I get home from work.

David Betz · 2012-04-30 06:58

Dr_Acula wrote: »

Thanks everyone, I'll do this when I get home from work.

Have you tried running whatever test code comes with fsrw 2.6? That's the filesystem code we're using to write the .pex file to the SD card. It would be interesting to know if that worked apart from the loader code.

Dr_Acula · 2012-04-30 07:13

Re post #48, I'm a bit confused there. Which program does this run? (does it even need a program?). I can't find the a.pex file after doing a search through all the propgcc folder. Sorry.

Re post #50, got that program and ran it. Startup code here

int main()
{
    int num;
    char *tokens[20];
    uint8_t buffer[80];

    stdinfile = stdin;
    stdoutfile = stdout;
    // Mount file system on touch161 board
    buffer[0] = 26; // SD MISO PIN
    buffer[1] = 25; // SD CLK PIN
    buffer[2] = 24; // SD MOSI PIN
    buffer[3] = 27; // SD CS PIN
   printf("Load SD driver\n");
    LoadSDDriver(buffer);
    printf("Mount\n");
    dfs_mount();
    printf("\n");
    Help();

It gets to help, but running any command, eg ls gives an I/O error.

So that seems to suggest an SD card problem and the driver. It isn't fat16 or anything like that by any chance?

What is the underlying sd card driver? If so, I'm wondering maybe the next step is to find a spin program that uses the same driver and test that.

David Betz · 2012-04-30 07:40

Dr_Acula wrote: »
Re post #48, I'm a bit confused there. Which program does this run? (does it even need a program?). I can't find the a.pex file after doing a search through all the propgcc folder. Sorry.

Re post #50, got that program and ran it. Startup code here
int main()
{
    int num;
    char *tokens[20];
    uint8_t buffer[80];

    stdinfile = stdin;
    stdoutfile = stdout;
    // Mount file system on touch161 board
    buffer[0] = 26; // SD MISO PIN
    buffer[1] = 25; // SD CLK PIN
    buffer[2] = 24; // SD MOSI PIN
    buffer[3] = 27; // SD CS PIN
   printf("Load SD driver\n");
    LoadSDDriver(buffer);
    printf("Mount\n");
    dfs_mount();
    printf("\n");
    Help();
It gets to help, but running any command, eg ls gives an I/O error.

So that seems to suggest an SD card problem and the driver. It isn't fat16 or anything like that by any chance?

What is the underlying sd card driver? If so, I'm wondering maybe the next step is to find a spin program that uses the same driver and test that.

If this is a PropGCC program that you're running then it is probably using dosfs.c for accessing the FAT filesystem. That isn't the code that the sd cache loader uses. It uses the fsrw Spin code. You might want to try running fsrw 2.6 and whatever test program comes with it to verify that it can access your SD card successfully.

jazzed · 2012-04-30 08:25

Dr_Acula wrote: »

Re post #48, I'm a bit confused there. Which program does this run? (does it even need a program?). I can't find the a.pex file after doing a search through all the propgcc folder. Sorry.

Step 3 creates file "a.pex" in your project folder.

Please try the attached SimpleIDE project with your dracblade.
It should work using LMM mode.

I've tested this on C3 using FAT32 4G and FAT16 2G uSD cards.
It is configured for DRACBLADE.

The program is a simple file access demo by Dave Hein. Example:

Load and mount SD: done.


Commands are help, cat, rm, ls, ll, echo, cd, pwd, mkdir and rmdir


> ls
autorun.pex   hello.txt


>

jazzed · 2012-04-30 18:36

Any possible update on testing with either the .zip I provided or the other method?

Thanks,
--Steve

David Betz · 2012-04-30 19:37

jazzed wrote: »

Any possible update on testing with either the .zip I provided or the other method?

Thanks,
--Steve

I ran this test successfully on my DracBlade with a 128M SD card.

Dr_Acula · 2012-05-01 01:45

Sorry jazzed, heaps of testing and lots of things not working and I didn't want to post questions every step as I still have some more things to test out first. I'll post when I get stuck or run out of ideas to test out. I guess this is what alpha testing is all about

David Betz · 2012-05-01 06:30

Dr_Acula wrote: »

Sorry jazzed, heaps of testing and lots of things not working and I didn't want to post questions every step as I still have some more things to test out first. I'll post when I get stuck or run out of ideas to test out. I guess this is what alpha testing is all about

Why not post your questions here. I have a similar setup if you do your testing on the DracBlade board so I can try to verify your results. BTW, mine is a v5 board if that makes any difference.

So, please post any questions you have. We'd love to be able to help you get your code working and also welcome the chance to fix any bugs that may be lingering in the PropGCC code.

jazzed · 2012-05-01 06:37

Dr_Acula wrote: »

Sorry jazzed, heaps of testing and lots of things not working ....

Thanks for your note. I'm just a little concerned about your sdcard troubles. I've seen where you've had some challenges with your new boards. I hope they come along without too many issues. I'm interested in helping you with software.

Dr_Acula · 2012-05-01 06:44

Can you do an experiment? The idea is to see if the boot-loader can read your SD card.

Set Memory Model to XMMC
Set the board type to DRACBLADE (no -SDXMMC)
Click the Burn F11 button to build and save bootloader to eeprom.
Using windows explorer copy the a.pex file to AUTORUN.PEX on your SD Card
Insert SD Card into your board
Open terminal window
Press reset
Copy result from the terminal to here

Thanks.
--Steve

I've got AUTOEXEC.PEX on the sd card. I followed all those instructions and it runs my program

BUT - it runs my program if I also remove the SD card. So I suspect the program is in eeprom, not on the SD card.

I presume what we are trying to do here is put the bootloader on eeprom and the program on SD card?

And now I am confused. Because I did that with the PropBOE file I modified and renamed Touch161. And I did it with the dracblade file.

Now in the c:\propgcc\propeller_load directory there is only one file that starts with "T" and that is TOUCH161.CFG However in the dropdown menu at the top of the SIDE there are now three entries - TOUCH161, TOUCH161 : PROPBOE, and TOUCH161-SDXMMC

So somewhere along the line the IDE seems to be creating files. Which one to use, and what exactly are these files? Can you view them or edit them?

Compiling with different ones causes different behaviour of the compiler. It is creating the a.pex file with one setup and not with the other.

Based on the experiment above, it seems as if these two new config files that have been created also affect whether the program is downloaded to eeprom or to an sd card.

I've just finished a 15 hour workday so my brain is a bit addled, but I'm getting very confused about how to ensure a program goes to an SD card or goes to the eeprom? Without knowing that for certain, it is getting harder to debug.

I have my suspicions it is fsrw not liking my SD cards, but I don't want it to be that one because it leads down the path of porting Kye's SD driver into propGCC.

New XMM hardware

Comments