"Unhandled Interrupt" in "fopen" with LPM enabled.

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

"Unhandled Interrupt" in "fopen" with LPM enabled.

Jump to solution
865 Views
myke_predko
Senior Contributor III

I'm trying to implement the low power modes on my product but I am receiving an "Unhandled Interrupt" message for my serial (Bluetooth) task when I open a (interrupt enabled) serial port using "fopen". 

 

I have tried adding the "_int_install_unexpected_isr();" statement with no luck.  "user_config.h" has the port (UART0/ittya enabled).  I'm running MQX 4.0.1.

 

I cannot find any reference to how I should handle the interrupt in the MQX documentation, AN4447 or AN4503 as well as searching the support forums. 

 

I have attached the serial code that I am using - it connects to a serial port in the product.  I am running this on my custom board with a K20 (which has a custom BSP) as well as a TWRK60N512 board with the standard BSP (and UART0/ittya) enabled, so I don't think it's an error with my BSP.  Note that the code in BT.c works fine when "MQX_ENABLE_LOW_POWER" is set to 0 - the problem comes up when I set "MQX_ENABLE_LOW_POWER" to 1. 

 

I should point out that when I use a serial port (UART3/ittyd) as my "iodebug" port (for "printf"), there isn't any error. 

 

I'm very sure that this is due to a lack of knowledge in the correct way to set up the interrupt based serial port in an LPM enabled system.  Any documentation references or example code would be appreciated. 

 

Thanx,

 

myke

Original Attachment has been moved to: BT.c.zip

Tags (4)
0 Kudos
Reply
1 Solution
528 Views
myke_predko
Senior Contributor III

Heya,

After prowling around the system, I discovered that the OPERATION_MODE tables in init_sci.c were different for UART0 & UART1 (the ones required by the application) versus the default UARTs used by the BSP I copied from.  I've attached the init_sci.c file that I created with the changes for review. 

I modified the OPERATION_MODE entries for the two ports and everything seems to be working now.

Could anybody please confirm that this is the right approach to solving this problem?

Thanx,

myke

View solution in original post

0 Kudos
Reply
2 Replies
529 Views
myke_predko
Senior Contributor III

Heya,

After prowling around the system, I discovered that the OPERATION_MODE tables in init_sci.c were different for UART0 & UART1 (the ones required by the application) versus the default UARTs used by the BSP I copied from.  I've attached the init_sci.c file that I created with the changes for review. 

I modified the OPERATION_MODE entries for the two ports and everything seems to be working now.

Could anybody please confirm that this is the right approach to solving this problem?

Thanx,

myke

0 Kudos
Reply
528 Views
myke_predko
Senior Contributor III

Just got a response from FSL - this was the correct way to handle this issue.

myke

0 Kudos
Reply