problem when using propeller-load with xmmc or xmm-single (propgcc default branch)
trancefreak
Posts: 186
I have a problem when trying to load a program in xmmc or xmm-single mode. I have a board with 128k sRAM attached and wanted to try it out.
sRam works and can be written and read. I made a program which writes 128k to the sRAM and reads the result back to test, if the result is correct. That works well. (Executed in LMM mode).
So the next step for me was to try out if a simple hello world program will run in xmm-single or xmmc mode.
My board configuration file looks as follows:
I built the program by using the following commands:
I tried -mxmmc and -mxmm-single, both dont't work.
To load the program to the propeller, I use the following command:
I get the following messages during load:
The sRAM propeller pins (defined in the board config file) are correct. The test program I wrote, which accesses sRAM by using SQI can write to the sRAM.
When I attach my logic analyzer, I can see, that there are no signals on pins 0,1,2,3 and 4,5 when loading the program with the propeller-load tool, so RAM doesn't get accessed.
When I execute my sRAM test program, I can see the clock, CS, SIO0-3 signals with the analyzer.
Does anyone know what I am doing wrong when I try to run a simple "Hello World" program in XMMC or XMM-Single mode on the sRAM?
Thanks,
Christian
sRam works and can be written and read. I made a program which writes 128k to the sRAM and reads the result back to test, if the result is correct. That works well. (Executed in LMM mode).
So the next step for me was to try out if a simple hello world program will run in xmm-single or xmmc mode.
My board configuration file looks as follows:
# pinballMCU_sram.cfg
clkfreq: 80000000
clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
sd-driver: sd_driver.dat
sdspi-do: 10
sdspi-clk: 9
sdspi-di: 8
sdspi-cs: 7
# cache geometry - 128 * 64 = 8192 byte cache
index-width: 7 # 2^7 = 128 cache lines
offset-width: 6 # 2^6 = 64 byte cache lines
cache-geometry: ({index-width} << 8) | {offset-width}
[sqi-sram]
sio0-pin: 0
clk-pin: 4
sram-cs-pin: 5
xmem-driver: sqi_sram_xmem.dat
xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | {sram-cs-pin}
I built the program by using the following commands:
propeller-elf-c++.exe -Os -Wall -mxmmc -m32bit-doubles -fno-exceptions -fno-rtti -Dprintf=__simple_printf -static -std=c++0x -IC:\PropGCC\lib\Util -IC:\PropGCC\lib\Communication -c C:\Users\Christian\Documents\CodeBlocks\sRamTest\main.cpp -o obj\Release\main.o propeller-elf-c++.exe -LC:\PropGCC\lib\Util -LC:\PropGCC\lib\Communication -o bin\Release\out.elf obj\Release\main.o -Os -Wall -mxmmc -m32bit-doubles -fno-exceptions -fno-rtti -Dprintf=__simple_printf -static -std=c++0x -s
I tried -mxmmc and -mxmm-single, both dont't work.
To load the program to the propeller, I use the following command:
C:\PropGCC\parallax\bin\propeller-load.exe -Dreset=dtr -I "C:/PropGCC/parallax/propeller-load/" -b PINBALLMCU_SRAM:SQI-SRAM bin\Release\\out.elf -r -p COM6 -t115200
I get the following messages during load:
Propeller Version 1 on COM6 Loading the serial helper to hub memory 10016 bytes sent Verifying RAM ... OK error: failed to connect to helper error: load failed
The sRAM propeller pins (defined in the board config file) are correct. The test program I wrote, which accesses sRAM by using SQI can write to the sRAM.
When I attach my logic analyzer, I can see, that there are no signals on pins 0,1,2,3 and 4,5 when loading the program with the propeller-load tool, so RAM doesn't get accessed.
When I execute my sRAM test program, I can see the clock, CS, SIO0-3 signals with the analyzer.
Does anyone know what I am doing wrong when I try to run a simple "Hello World" program in XMMC or XMM-Single mode on the sRAM?
Thanks,
Christian
Comments
What could be the reason that the helper does not get started? Can I find out which file contains the serial helper to check, if it is corrupt?
Christian
Yes, for my sRAM test program I'm using C and propeller-load. It's just a simple program which uses sqi to write and read from the sRAM so I can be sure it works.
Regarding the xmm-single test (propgcc default branch) with a simple hello world program:
I tried it with my quickstart and my own designed board. Both behave the same (failed to connect to helper).
So it looks like there is no communication possible after the helper is loaded to hub ram. I assume that there is no way to test, if the serial helper is started on the board (some debug option to send something to the pc)?
Unfortunately implementation documentation for both xmm versions is practically non-existent. The old programmer's adage applies: "The code is the documentation." Hopefully we can address this shortcoming in the near future.
Can you show your .cfg file and your SRAM PASM driver here?
Oops. Sorry about that. My attention span is too short today.
My configuration file is in the first message. I tried to use this cache driver: sqi_sram_xmem.dat
But it looks like the cache driver is never invoked because the serial helper does not start / communicate with the propeller-load program.
What do I need to get that working? The advantages you mentioned are exactly the reasons why I wanted to use the default branch plus gdb debugging.
@David: Does XMM work for you in the default branch? I did the checkout yesterday, so I should be up to date.
Christian
Thanks very much David!
I'm using the Microchip 23LC1024. The sqi sram driver should support this chip. I had a look at the source and all the commands match the ones of the chip.
Christian
When I switch back to the release branch, XMMC with eeprom works:
David, I hope you can find the problem that I can play with the default branch features :-)
Thanks,
Christian
Thanks,
David
The config file I am using for eeprom is as follows:
clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 sd-driver: sd_driver.dat sdspi-do: 10 sdspi-clk: 9 sdspi-di: 8 sdspi-cs: 7 # cache geometry - 128 * 64 = 8192 byte cache index-width: 7 # 2^7 = 128 cache lines offset-width: 6 # 2^6 = 64 byte cache lines cache-geometry: ({index-width} << 8) | {offset-width} xmem-driver: eeprom_xmem.dat eeprom-first: TRUEThe program is this one:
#include <stdio.h> #include <propeller.h> #include <stdint.h> /** * This is the main BoardTest program file. */ int main(void) { while (1) { printf("Hallo!\n"); waitcnt(80000000 + CNT); } return 0; }This works when I use the release branch. Do you use the most recent default branch sources?
When I'm back at home I'll also test with a quickstart.
Christian
Thanks! I'll try this code later this evening. I am using the most current sources from the default branch. I'm always on the bleeding edge! :-)
Christian
I tried it with my quickstart board by using the default quickstart configuration.
The default quickstart config file looks as follows:
# quickstart.cfg clkfreq: 80000000 clkmode: XTAL1+PLL16X baudrate: 115200 rxpin: 31 txpin: 30 # cache geometry - 128 * 64 = 8192 byte cache index-width: 7 # 2^7 = 128 cache lines offset-width: 6 # 2^6 = 64 byte cache lines cache-geometry: ({index-width} << 8) | {offset-width} xmem-driver: eeprom_xmem.dat eeprom-first: TRUEIt doesn't work. I get the following output:
When I use the release branch, it does work.
Is there a possibility I built the branch in a wrong way?
What I did:
I downloaded the latest version of MinGW and MSYS, installed them and checked out the default branch.
In the MSYS console window, I navigated to the checkout directory and started the build (directly in the propgcc checkout directory):
. ./rebuild.sh
It looks like everything got built, the gcc compiler does work, also the propeller-load program, but there is no connection to the helper.
Is there anything that you could think of I did wrong or I should try differently?
Thanks,
Christian
If you have the latest defult branch you might want to try "hg pull", "hg update default", "make clean-all", then "make" ...
Using make works in all measurable respects, but build.sh (jbuild.sh 1) has failed to create a good image (for me at least). The build will complete, and the compier/tools work, but programs don't work.
I've checked out the branch yesterday. So I should be up to date. I will do an update now and rebuild it as suggested by you. I will post my results tomorrow when everything is rebuilt.
And I want to thank you and David for your help and input in your spare time!
Thanks,
Christian
Christian
Your code looks like this:
[sqi-sram] sio0-pin: 0 clk-pin: 4 sram-cs-pin: 5 xmem-driver: sqi_sram_xmem.dat xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | {sram-cs-pin}But it should look like this:
[sqi-sram] sio0-pin: 0 clk-pin: 4 sram-cs-pin: 5 xmem-driver: sqi_sram_xmem.dat xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | 0x01 xmem-param2: {sram-cs-pin} << 24The chip select handling for the sqi_sram_xmem driver uses a flexible scheme for handling chip select that works with either simple single pin CS as well as various mux options and also a C3-compatible counter based scheme. The 0x01 at the end of param1 selects a single pin CS and the pin number is the high byte of param2.
Unfortunately, propgcc/demos/ebasic3 still doesn't work correctly so I have to look further to find that problem. My xmem driver test program works fine though.
[sqi-sram] load-target: ram sio0-pin: 0 clk-pin: 4 sram-cs-pin: 5 xmem-driver: sqi_sram_xmem.dat xmem-param1: ({sio0-pin} << 24) | ({clk-pin} << 8) | 0x01 xmem-param2: {sram-cs-pin} << 24I'm still looking into why xmm-single isn't working.
Hi David,
Thanks for the hint, I've updated my configuration.
I have a problem when using make to build propgcc from sources. I get the following error message:
checking size of mp_limb_t... 0
configure: error: Oops, mp_limb_t doesn't seem to work
make[1]: *** [configure-gmp] Error 1
Do I have to install a specific library?
Christian
I previously built the branch with ./rebuild.sh which uses jbuild.sh I think. The build itself worked.
Currently the build is running with make. I googled and found the following hint:
With make PWD='pwd -W' the build now runs for about 20 minutes now. Without that, the build stopped after a few minutes with the error I posted above.
I hope it suceeds ;-)
Christian
@Steve: Did you have to do something special to get a successfull build with make?