ChibiOS on iNemo v1

[zuh]

Hi all, thought I'd ask for some eyes on our attempt to write some IMU code for the ST iNemo v1 board using unstable (well, trunk) ChibiOS.

I have created a rudimentary board file (copying an existing implementation and adjusting that) as seen at

https://github.com/snowcap-electronics/ ... T_INEMO_V1

and got the traditional heartbeat LED going, as well as button input and serial output.

However, when I moved to ADC (and I²C) everything broke down. The iNemo v1 has two 2-axis gyros which I'm trying to read from, and I think it actually manages to do a read according to breaking in gdb and looking at the sample buffer it seems to be filled with somewhat sensible-looking data.

But after that the execution never returns to the ADC callback, hearbeat dies and breaking in gdb claims the it is sitting in the idle thread:

^C
Program received signal SIGINT, Interrupt.
_idle_thread (p=0x0) at ChibiOS/os/kernel/src/chsys.c:59
59 }

I have tried all sorts of things to debug this but quite frankly I'm stumped and don't know where to look next. Any suggestions on what to try would be most welcome.

Here's the main code for the application:

https://github.com/snowcap-electronics/ ... src/main.c

[Giovanni]

Hi,

Try to run with the debug option ON (in chconf.h), the state checker could you give an hint of what is wrong. Once the program is halted because an error you can inspect the global debug variables using the ChibiOS Eclipse plugin and also get a stack trace.

Also try to add things incrementally, first ADC then I2C etc.

Giovanni

[zuh]

Heh, good point about the debug options, unfortunately all they helped was fixing an unintentional call of I-class API.

There seems to be no error state which ChibiOS would catch with CH_DBG_SYSTEM_STATE_CHECK, CH_DBG_ENABLE_CHECKS or asserts.

I also tried saying the iNemo was STM32F10X_MD rather than _HD (which I believe it is) but no difference there either.

So I'm back into being confused

I know the application code should be ok, since it's pretty much the same as a working code for the discovery boards. The obvious suspect then is the board definition, but I can't figure out what could be wrong with it.

[Giovanni]

iNemo v2 should be an HD device.

Can you try to make a synchronous conversion using adcConvert()? (put callbacks to NULL) Just to see if it makes a difference.

Anyway, if the heartbeat stops then something strange happened, are interrupts enabled when it is stuck in the idle thread?

Also verify if all configuration files and .ld files in your application are from the same ChibiOS version.

Giovanni

[kulve]

iNemo v2 should be an HD device.

We are actually using the v1 but it has the same MCU.

Anyway, if the heartbeat stops then something strange happened, are interrupts enabled when it is stuck in the idle thread?

What's the best way of verifying that..?

Thanks.

[Giovanni]

Good point, you should inspect the BASEPRI register but if I remember well it is not shown in the Eclipse debugger. Could you try the other suggestions?

Giovanni

[zuh]

This is fun, I get to learn all new gdb/openocd commands If only the code would start to work as easily...

But anyway, I tried with sync ADC convert, no change.

Then I teached myself how to get a dump of the registers with gdb/openocd and below is the result. What I googled makes me believe that the interrupts _should_ be enabled (both primask and basepri are zeroed) but maybe someone actually knows it and enlightens me.

(gdb) monitor reg
===== arm v7m registers
(0) r0 (/32): 0x00000000
(1) r1 (/32): 0x20000800
(2) r2 (/32): 0x08001E70
(3) r3 (/32): 0x200008F8
(4) r4 (/32): 0x08000461
(5) r5 (/32): 0x00000000
(6) r6 (/32): 0x00000000
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0xFFBFFFED
(13) sp (/32): 0x20000998
(14) lr (/32): 0x08000353
(15) pc (/32): 0x0800046D
(16) xPSR (/32): 0x21000000
(17) msp (/32): 0x20000400
(18) psp (/32): 0x20000998
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x02
===== cortex-m3 dwt registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

[Giovanni]

Hi,

Yes, interrupts are enabled, very strange.

The only thing I notice in your main is the ADC configuration that specifies ADC_CR2_EXTSEL_SWSTART, current demos do not put that value in CR2, see the test application ./testhal/STM32F1xx/ADC
I am not sure this would lock the system however, anyway, copy the ADC configuration from the demo, probably you could just run the demo as-is just swapping the board files in order to verify basic ADC functionality (I just retested it on my Olimex STM32-P103 and the test application worked).

Giovanni

[zuh]

Some new discoveries on the iNemo business.

First, I tried to get the ADC testhal program to built and run against my board files but for whatever reason it just hangs in port_init(). I quickly gave up that and copied the configuration over to my project, but no change in behavior

But then I discovered that if I sample only one channel (rather than all four or even just two) the program stays alive.

That doesn't tell me anything about the actual problem, nor am I sure if the data coming in is valid, but at least it's progress!

[Giovanni]

It cannot hang in port_init(), it is such simple code and it should be running with interrupts disabled, the OS is not even stated at that point.

There must be something wrong with integration or tools, are you using the standard Makefiles? compiler version? standard compiler options? using the correct linker script? including the correct directories in Makefile? using the standard startup code? Linked libraries with project?

Giovanni