I added some more debugging output to the "threads" command;
ChibiOS/RT Shell
ch> threads
addr stack (limit) prio refs state time name
20000A28 20000754(20000400) 64 1 WTOREVT 0 main
20000968 200009C4(200009B4) 1 1 READY 311670 idle
20003970 200039EC(200039BC) 2 1 READY 0 usb_lld_pump
2000BBF8 2000C01C(2000BC44) 64 1 SLEEPING 2 blinker
20004120 2000424C(2000416C) 2 1 WTOREVT 8 lwipthread
2000C2B8 2000C67C(2000C304) 3 1 WTSEM 5 none
2000C770 2000CE2C(2000C7BC) 64 1 CURRENT 0 shell
ch>
Looks like there is adequate space there now. I also looked with GDB at the memory from the limit address as. For the blinker thread I see...
(gdb) p /x *(0x2000bc44)@64
$14 = {0x55555555 <repeats 18 times>, 0x8021c61, 0x0, 0x55555555, 0x55555555, 0x8021c61, 0x0, 0x55555555,
0x55555555, 0x55555555, 0x55555555, 0x55555555, 0x55555555, 0x8001091, 0x11555555, 0x20036a8, 0x2000bcf4,
0x2000bbf8, 0x1, 0x800d397, 0x2000bd04, 0x2000bd04, 0x1, 0x200036a8, 0x3e, 0x8021c61, 0x0, 0x55555555,
0x55555555, 0x55555555, 0x55555555, 0x55555555, 0x55555555, 0x8001091, 0x11000001, 0x20036a8, 0x3b4a,
0x2000bbf8, 0x1, 0x800d397, 0x2000bd54, 0x2000bd54, 0x1, 0x200036a8, 0x3b4a, 0x800daf9, 0x1}
Just enough head room now?
James.
stm32f4 discovery fatfs problem
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: stm32f4 discovery fatfs problem
You can do this more easily using the ChibiOS debug plugin for Eclipse. If it is not a stack overflow then it is hard to say what is going wrong, I recommend splitting the complex application into simple parts and disable all of them, then reintroduce parts one by one until the problem appears again.
Giovanni
Giovanni