Port of code from ST_NUCLEO_L152RE not working on ST_NUCLEO_

[klpauba]

ChibiOS-RT: Git branch stable_2.6.x
Platform: STM32
Board: ST_NUCLEO_F401RE

I'm writing code to drive an LED for bidirectional, short range (<25 mm)
wireless communications (see http://mecrisp.sourceforge.net/ledcomm.htm). My
hope is to eventually provide a (slow) Serial and UART driver to the community.

I have a prototype version running successfully on the ST_NUCLEO_L152RE board
but when I ported it to a ST_NUCLEO_F401RE board, the LED is not able to detect
the light from another LED.

I've made sure the mcuconf.h file is set up properly for each board:

* Both boards use the same pads for anode (PB5) and cathode (PB4).

* Both boards use TIM2 for the GPT (5 kHz frequency)

* Both boards use the same halconf.h and chconf.h files.

The only difference in the code running is this:

* The discharging and charging of the parasitic capacitance is roughly equal
between the two boards. Since the L152 runs with a 32 MHz clock and the
F410 uses a 84 MHz clock, some loop iterations were adjusted so that the
charge/discharge times were within 1 microsecond.

Here's a basic outline of the processing:

* GPT triggers a call back at 5 kHz rate. The callback simply resets a
binary semaphore.

* A thread waits on the binary semphore, resets it and performs the main
state machine for the LED communications. In a particular set of states,
the LED is prepared to detect the shining of another LED at which time it
charges the parasitic capacitance. It then stores the current value
returned by halGetCounterValue(), enables the EXT driver to detect the
falling edge of the LED cathode via a EXT callback, and switches the
cathode pad to an INPUT.

* The EXT callback first disables EXT interrupts for the channel and
subtracts the saved halGetCounterValue() with the current one. The count
is used to decide if the other LED is shining (value below a certain
threshold indicates light).

I don't seem to be getting any interrupts on the high to low transition of the
F401's cathode.

Before I share the logic analyzer screenshots and the code, I thought I would
check to see if anyone can identify any "gotchas" or if there are any known
problems on the 2.6 branch. Has there been any report of problems with the EXT
module on the F401?

Any ideas on what I might check? Might you have any debugging hints?

Thanks!

[Giovanni]

The code should be mostly portable except for initializations.

I would consider a bug somewhere in the STM32F401 support, it is relatively "new". Is it the EXT interrupt that you don't receive? It is possible there is an error in the interrupt vector name or something like that.

Giovanni

[klpauba]

I found that the interrupt is getting called (I verified it in the debugger).

Here's what's odd. Take a look at the logic analyzer display:



The range between the green markers (at around +8.5 ms) shows the F401's LED shining on the L152's LED. You can clearly see the L152's trailing edges where (I assume) the EXT handler is called for each. However, when the L152's LED shines on the F401's LED, there are no trailing edges except at the end of the GPT period.

I would have expected the same pattern on the F401 traces starting at around the +10.5 ms marker.

It's almost as if the F401 cathode shown in the logic analyzer display is not the same one triggering the EXT interrupt.

Thanks for taking the time to respond, Giovanni!

PS: Sorry, my first attempt at including images seems to have failed miserably!

[Giovanni]

Since timings are so critical, could it be that the L151 and F401 have different settings for output pin speeds? please give a look to the RM in the GPIO section. GPIO speed settings should be very different among the two.

Giovanni

[klpauba]

All the output modes are set using the statement:

Code: Select all

   palSetPadMode(led->cathode_port, led->cathode_pad, PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_LOWEST);

PAL_STM32_OSPEED_LOWEST is defined in GPIOv2. I think that's valid for both boards (I see GPIOv2 referenced in both ChibiOS-RT/os/hal/platforms/STM32{F4xx,L1xx}/platform.mk).

[klpauba]

Well, this is embarrassing!

It turns out that the LED on the current-limiting resistor on the cathode instead of the anode. This, I assume, prevented the proper charging of the parasitic capacitance.

Once I changed things around, all is working well now! Sorry for the fire alarm and thanks for the replies!

[Giovanni]

np, you are welcome