FreeMaster 3 randomly Error 0x80000101 (s32k344)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FreeMaster 3 randomly Error 0x80000101 (s32k344)

Jump to solution
2,834 Views
JoDo
Contributor III

Hello,

I am working with FreeMaster 3.1.2.4 and with S32K344 controller. It works perfectly, but after some time > 5...10Sec I get an erro 0x80000101 (see picture) for each variabe im trying to read. When I reset the controller, freemaster continues without error, but after about 5...10Sec the same error comes up

I also measured the execution time of the function that generates the data and it was less than 1Ms. When I comment this function out, I do not get an error. It seems that an error occurs and the FreeMaster gets confused.

does anyone have any idea where something is going wrong here?

Translated with www.DeepL.com/Translator (free version)

JoDo_0-1637232804165.png

 

0 Kudos
1 Solution
2,760 Views
iulian_stan
NXP Employee
NXP Employee

Hi @JoDo,

Thanks for sharing your project. I was able to reproduce the issue and it looks that the UART runs into "Receiver Overrun" state (STAT register  OR flag). The board receives too more requests from the host (FreeMASTER tool running on PC) than the embedded side can process. FreeMASTER driver has no sufficient time to process all incoming requests and as consequence OR flag is set to 1. From that point the serial will no longer accept messages till the flag is cleared. FreeMASTER Driver is not "aware" of this flag because it does not control the peripheral except for sending and receiving messages. Even though the desktop tool keeps sending messages they are ignored by the UART, causing Timeout Errors.

Here are a few things I tried to fix it:

  1. While in debug, I cleared the OR flag once I got timeout errors and was able to reconnect to the board without resetting it.
    In this case you can use the debugger or add some logic that monitors the STAT register.
  2. I switched to interrupt mode and had no issue running the app. I chose the short interrupt to make sure that messages are picked from serial line as soon as they come, the processing is still done in the poll function.
    The interrupt can be enabled from Configuration Tool like this:
    1. Set the Callback function on "Generinc Interrupt Settings" tab
      Capture.PNG

      Note: FMSTR_SerialIsr is defined in "freemaster_s32k344_lpuart.h".

    2. Enable the interrupt in the "Interrupt Controller" tab

      Capture1.PNG

       

Hope it helps.

View solution in original post

6 Replies
2,826 Views
iulian_stan
NXP Employee
NXP Employee

Hi @JoDo,

What communication mode are you using ? (short/long interrupt or polling)

I suspect that FreeMASTER driver has no sufficient time to process the communication phase (ex: when it tries to read/write data over UART another interrupt with higher priority stops the read/write execution and the driver is unable to recover).

Potential workarounds could be:

  • Switch from interrupt to polling mode
  • Increase FreeMASTER interrupt priority
  • Use BDM plugin (see note)

Note: BDM plugin does not require FreeMASTER Driver enablement in the embedded application. The drawback of this approach is that is does not allow the use of both Debugger and FreeMASTER at the same time as the debug interface would be used by the later, additionally, some of the advanced functionalities (such as recorder) are not available in this mode.

0 Kudos
2,816 Views
JoDo
Contributor III

Hi,

Thanks for the reply. 

I am indeed using Freemaster in polling mode. I call the FMSTR_Poll(); in the main-loop before any other function. There are also no interrupts enabled.
I get data and do some calculations with it, that's all. I dont understand why it crashes.

Is there  a reset possibility in the code for the FreeMaster if it has this communication problem?

 

0 Kudos
2,799 Views
iulian_stan
NXP Employee
NXP Employee

There is no reset functionality. FreeMASTER Driver should be able to handle wrong/incomplete/corrupted messages. I'm not sure whether your issue happens on protocol or lower communication level. Is it possible to share your project to check it on our side ?

0 Kudos
2,791 Views
JoDo
Contributor III

Hi @iulian_stan,

I have sent you a private message with my S32DS project (RTD 1.0.0 CD) attached.

Thank you very much in advance!

Regards,

JoDo

0 Kudos
2,761 Views
iulian_stan
NXP Employee
NXP Employee

Hi @JoDo,

Thanks for sharing your project. I was able to reproduce the issue and it looks that the UART runs into "Receiver Overrun" state (STAT register  OR flag). The board receives too more requests from the host (FreeMASTER tool running on PC) than the embedded side can process. FreeMASTER driver has no sufficient time to process all incoming requests and as consequence OR flag is set to 1. From that point the serial will no longer accept messages till the flag is cleared. FreeMASTER Driver is not "aware" of this flag because it does not control the peripheral except for sending and receiving messages. Even though the desktop tool keeps sending messages they are ignored by the UART, causing Timeout Errors.

Here are a few things I tried to fix it:

  1. While in debug, I cleared the OR flag once I got timeout errors and was able to reconnect to the board without resetting it.
    In this case you can use the debugger or add some logic that monitors the STAT register.
  2. I switched to interrupt mode and had no issue running the app. I chose the short interrupt to make sure that messages are picked from serial line as soon as they come, the processing is still done in the poll function.
    The interrupt can be enabled from Configuration Tool like this:
    1. Set the Callback function on "Generinc Interrupt Settings" tab
      Capture.PNG

      Note: FMSTR_SerialIsr is defined in "freemaster_s32k344_lpuart.h".

    2. Enable the interrupt in the "Interrupt Controller" tab

      Capture1.PNG

       

Hope it helps.

2,736 Views
JoDo
Contributor III

Hello @iulian_stan,

Thank you very much for debuging my project and the detailed description.

I have tried it today. And as you suggested I changed it to short interrupt, since then I have not had any communication errors either.

Thanks a lot for the support, it helped!

Regards,

JoDo

0 Kudos