RT1176 GPIO Falling edge / TMR1 interrupt delay after boot

[blukasi]

Hello,

I am currently working on a project that will be using the RT1170 series MCU in one of our devices to handle all of the underlying control and communication between internal peripherals, touch screen, SDRAM, etc.. For the UART module, we have designed the system to use LPUART1 for 1 of 2 serial modules and use GPIO and TMR1 interrupts for the other module. 

I am successfully able to generate a stable "clock" with the timer that has it's counter reset with each frame of data that comes in on RX. And have been able to successfully transmit and receive over 1GB with less than 1% error. 

The issue only appears after a system boot. If I reset the system, after the pin and board init's, I call my serial_write() function which will sit and transmit a string over TX until it reaches the '\0' terminator. The system then sits in a while loop and waits for user input over RX. The first byte that is received over RX after system boot will be incorrectly framed and with an oscilloscope it can be observed that about 50usec is spent in the TMR1 IRQ. And this phenomenon only appears in the TMR1 IRQ after boot, only the once during runtime, and is repeatable on multiple EVK boards. 

Below is my c code and a SC of the oscilloscope.

 (NULL byte sent as first byte after boot)

 (512 Byte string sent over RX after NULL byte)

Any insight would be appreciated,

Thanks,

B.

[diego_charles]

Hi @blukasi 

I hope you are doing excellent. 

It seems that you are implementing a SW UART. Where the QTIMER IRQ is generating the timing to write and sample each bit thought GPIO. Also you are using a custom ring buffer to store received data. Please correct me if I am wrong.

Therefore I am understanding that if the QTIMER fails its required timing you won't be able to sample received bits correctly.

So if we  rule out  the UART functionality and simple leave the QTIMER IRQ working, we would see that  the first interrupt, after POR , will take longer than expected? It will be interesting for us to see if this behavior can be replicated with our tmr_timer_cm7 SDK example.

All the best, 

Diego.

[blukasi]

Hi Diego,

Thanks for getting back to me. I ran the qtmr SDK example (with the 50ms-10s-1min delays) and added a pin to pulse whenever the program enters the IRQ. I also shortened the timer to the 8 usec range as I believe the time constraint may be where my issue lies. 

After setting up the board and hooking up the oscilloscope I can see there is an unexplainable delay in the first iteration through the IRQ. You can see it enter, delay for 2.4370 usec (beyond the typical 196 ns it takes to write a 1 then a 0 to the pin), then exit the IRQ. After that first pass, the system returns to a stable period and each subsequent pulse has a write delay of ~196 ns.

So it appears it may be a limitation of the hardware?

I've included a screen shot of the oscilloscope below.

Hopefully this shed some light on the matter.

B.

[diego_charles]

Hi  @blukasi 

I am sorry for not being able to reply sooner. I was able to replicate the issue last week: 

• The first IRQ takes longer too resume (~2400 uS). I used the RT1170's  M7 project to test.

After discussing with colleagues, I proceeded to test the demo for  RT1170's M4 project ,which is completely linked to RAM :

       The first IRQ resumes in the expected time. 

Then, I linked the M7 project to RAM and I found the expected behavior. Let me know if you face any issues to do this.

Could you try to replicate this on your end?

Diego.