Problem with receiving infrared remote control codes

Hello everybody,
I am creating a led strip controller using a bluepill. I would like to add an infrared remote control (it already has a connection to an esp8266 and an apds9960 gesture sensor), so I tried to use the IRMP port done by karawin (https://github.com/karawin/irmp-master). Even if the library worked with some test programs, when I integrated it into my bigger project it just stopped returning any results. I was only interested in the NEC protocol, and I’m not so sure about the results of IRMP, so I created my own library. It can be found at https://github.com/fotisl/NECIRDecode, and it is a simple state machine that decodes only remote control codes by NEC IR transmission protocol. But, once again, it works great with some simple test programs, but when I integrate it into my bigger project I get issues. I am thinking of some interaction with some other hardware, but I don’t know how to locate the problem.
My library uses a HardwareTimer. I tried with every HardwareTimer available and I still get the same problem. The rest of the project uses USB Serial port, Serial port 1, I2C at PB13/PB15 (soft, not hardwire), SPI2, some GPIO pins and 2 pins for ADC.
Any ideas on what can be the problem, or how can I debug this? I have an stlinkv2 but it seems a little bit difficult to debug this since interrupting execution will get me out of sync for sure.

Regards,
Fotis

it may have ran out of memory, you may like to check the available stack space e.g.
http://www.stm32duino.com/viewtopic.php?f=18&t=2065

ag123 wrote:it may have ran out of memory, you may like to check the available stack space e.g.
http://www.stm32duino.com/viewtopic.php?f=18&t=2065

i’m getting funky usb serial stalls as well, in particular when i included freertos as part of it, i noted that freertos allocated an 8k block as its heap which it used to manage its tasks’s stacks. with other objects i noted that some 12k (8k for rtos + 4k for others) are used on the heap after i compiled it and check the map file
http://www.stm32duino.com/viewtopic.php … 070#p27711
if i remove freertos relieving more than 8k, the sketch runs. hence in my case i’d think i simply run out of memory but i’m not too sure about it too
for smaller sketches with freertos it runs

The problem is that I keep getting the same problem with my library too, which doesn’t use RTOS and works great in simple programs.
Btw, my led strip project doesn’t use any timers.

Fotis

there is some discussion here http://www.stm32duino.com/viewtopic.php?f=3&t=2091 about the uart ring buffer, which apparently stalls if some of the ring buffer variables is not declared as volatile. you may want to try those fixes if it relates to usb – serial stalls, i’m not too sure if that ring buffer relates to usb-serial hope it helps

I have verified that the interrupt handler is being called every 50us, as it soon be, using a logical analyzer. Thus there is no issue with the timer.

I am pretty confident that the uart ring buffer is not related to my problem, but I should definitely check if some variables changed within the interrupt handler need to be declared as volatile.

Fotis

ag123 wrote:there is some discussion here http://www.stm32duino.com/viewtopic.php?f=3&t=2091 about the uart ring buffer, which apparently stalls if some of the ring buffer variables is not declared as volatile. you may want to try those fixes if it relates to usb – serial stalls, i’m not too sure if that ring buffer relates to usb-serial hope it helps

Actually if you don’t declare the variable var as volatile, and you only change var at interrupt context, then the compiler may evaluate the condition inside your while loop at compile time and either transform it to a while(1), remove the whole loop if the condition evaluates to 0, or change it to some other expression depending on your condition.

The problem is that I declared all variables that change inside the interrupt handler as volatile and I still have the same issue. I think I’ll have to check the output of the compiler to see if anything gets optimized when it shouldn’t.

Fotis

gcc has been known to be *removing codes* if for whatever reason it seemed unused

this in particular as we tried the whetstone benchmark and noted such behaviour, but it did give ‘unfairly’ high benchmarks with the -O3 optimizaitions
http://www.stm32duino.com/viewtopic.php … &start=160

the main ones would be where local variables are declared and used in some assignments but is otherwise unused. i’m not too sure if declaring those variables volatile could prevent the compiler from ‘optimizing away’ codes that way

but i’d guess it won’t be easy to tell the cause and a closest thing may be to attempt a debug but still that may not be easy to find the cause of the stalls

With the help of a logic analyzer I found out that the problem is actually caused by interference from the rest of the components. Adding an RC filter at the supply of the TSOP4838 helped a little bit, and I’m now checking if powering from the +5V supply helps too.

Thanks for your replies!