Overheat on MKW22 MCU

[matthieuremacle]

Hello everybody,

For procurement reasons, we had to switch from MKW21 to MKW22 MCUs on our production line. They are supposed to be pin-to-pin compatible. 

After having resolved a big problem with the configuration of the MKW22 clock (see my previous post External crystal clock on MKW22 MCU not working), I now have a new problem with this processor.

We just started to produce boards with the MKW22 and we observed a problem during production: around 1 board over 3 produced does not work, the problem seems to be a the 802.15.4 level. The other produced boards work without problem.

I also observed that all the non working boards are overheating: When I plug a board and the software is running on it, it start heating and reach 50°C after +/- 20 seconds. On the working boards, the temperature of the MCU is stable at 25°C in the same conditions.

I suppose that the problems observed on the 802.15.4 are coming from this overheating problem (the clock must be slightly different because of the temperatyre). Please note that all the boards we produced previously with the MKW21 had no problem.

Where does this behaviour could come from ? What can we do to prevent it ? Is it due to hardware or software ?

It could be a peripheral badly initialised with no default reset value, or a random one, but which one ?

This is really urgent and the production is now stuck because of that. 

Best regards,

Matthieu.

[gerardo_rodriguez]

Hello Matthieu,

I understand your concern, sorry I was not being completely clear. The reason we provide application code is to give the customers a working solution that they can use as base for their development.

KW22D and KW21D are almost pin-to-pin compatible but the fact that there is a USB module available may or may not affect your implementation depending on your layout. That is why I shared our recommendation on the unused USB pins.

The line “SIM->SCGC5 |= SIM_SCGC5_PORTB_MASK | SIM_SCGC5_PORTC_MASK;” enables the clock gating for the PORT B and C which is needed to configure the MCU pins that are connected to the radio. You can refer to the Table 4-2. Internal Connections of the reference manual too see how the MCU is connected to the radio. You need these clocks enabled to configure the pins, otherwise a write to the PORT registers would result in a hard fault. I don’t see why not having this line could cause the overheat you are mentioning. I recommend you to compare your initialization code with one of our examples.

You can find the Linux version of the Connectivity Software in the Protocol Stacks section of the “SOFTWARE & TOOLS” tab from the KW2xD product page.

The connectivity test application is a simple application that provides an user interface through UART to perform basic transmission and reception tests of the radio. This application is based on the Simple Media Access Controller (SMAC) stack, which is a small codebase with some features of the 802.15.4 protocol.

You are right, you would need to adapt the source code to be compatible with your board, but it should not be a hard task. The application developed for the FRDM-KW24 flashes the LEDs in the board at the beginning of the application and uses the UART connected to pins PTE0 and PTE1 for the user interface. To disable the LEDs pins, you can set the gLEDSupported_d macro to FALSE in LED.h. If you share your schematics I could assist you with making this application compatible.

The application is located at “<ConnSw>\boards\frdmkw24\wireless_examples\smac\connectivity_test\”. You can follow the "SMAC Quick Start Guide.pdf" document in “<ConnSw>\docs\wireless\SMAC\” for steps on how to build and run this application.

About your third question, there is no errata for the KW2xD family.

Let me know if you have any issue in running the Connectivity Test application.

Regards,

Gerardo

[matthieuremacle]

Thank you for this more complete answer.

I tried to execute the test application on my custom board but when I do so, I see nothing on the UART, even with a logic analyser. By default, it uses UART1, right ?

UART1 is the only UART port available on this hardware. Other ports and not routed, and the USB can't be used neither.

I'm expecting to see data at boot (the NXP in pixel art that is supposed to be sent at the beginning). Do I have to do any particular action to enable the UART interface ?

[gerardo_rodriguez]

Hello Matthieu,

Yes, the connectivity test application uses the UART1 by default on pins 15 and 16 (PTE0 and PTE1). You don't need to modify anything in the application to enable the UART1. Do you have any external HW on these pins that could be interfering with the signals?

The NXP logo should be printed in the PrintMenu(cu8Logo, mAppSer) function inside the main_task() in the connectivity_test.c file.

Can you debug the application to see if any error is being generated on the initialization?

You could even try a simpler application such as the UART driver example in <ConnSw>\boards\frdmkw24\driver_examples\uart\polling\ to verify that the UART can work and then try the connectivity test.

Let me know your findings.

Regards,

Gerardo

[matthieuremacle]

Hi Gerardo,

I've successfully communicated between a working processor and a non-working processor through the test application. 

So it seems that the hardware is not responsible for these communication problems.

So I tried to discover differences between the test application and our application and they are very alike. Today, I still have found no difference that would explain these emission problems I have. 

Do you have a contact at NXP who's expert of these processors ? Someone with experience with the MKW22 and to whom I could speak directly ? I'm out of ideas to resolve this, I have the feeling I already tried everything...

Best regards,

Matthieu.

[matthieuremacle]

Hello,

I've news: 

I did a minor modification of the connectivity test application. The modification is as follow: on the freeRTOS application, I updated connectivity_test.c with the following modifications:

Lines 883 -> 888:
Before:
if(bTxDone || failedPRBS9)
{
    failedPRBS9 = FALSE;
    bTxDone     = FALSE;
    PacketHandler_Prbs9();
}

After:
if(bTxDone || failedPRBS9)
{
    static uint32_t test = 0;
    test++;

    for(int i = 0; i<0x100000; i++)
        __asm__ volatile ("NOP");
    gAppTxPacket->u8DataLength = 4;
    FLib_MemCpy(gAppTxPacket->smacPdu.smacPdu, &test, 4);

    failedPRBS9 = FALSE;
    bTxDone     = FALSE;
    PacketHandler_Prbs9();
}

With these modifications, the packet sent on the air with the connectivity test application is different at each time, and is sent less often.

I executed this same application on a working processor and on a non-working processor.
1) On the working processor, every packet is received, without exception, and the count is correct.
2) On the non-working processor, a lot of packets are missing (I can see it because the count is not correct). Sometimes, no packet is sent at all during a long time (several seconds), and when I run my fingers on the board, the packets are sent again.

I realise now that I always considered that no packet was sent at all, but it seems that some packets are sent, but not all of them. Because of this behaviour, our custom application can't work.

[gerardo_rodriguez]

Hello Matthieu,

At this point, we need to make sure if the problem is board or MCU related. Can you please try doing an ABA swap? 

Swap the suspected MCU (A) from a failing board with a good MCU (B) from a working board. With this test we can confirm if the failure follows the MCU or the board.

Regards,

Gerardo

[gerardo_rodriguez]

Hello Matthieu,

The only difference between the MKW21D and MKW22D is the USB module. If you won't use the USB module, our recommendation is to leave the USB_Dx pins floating and connect VREGIN and VOUT33 pins together and tie to ground through a 10k ohm resistor.

If possible, please share your schematics and layout. If you can't publish them here, you can send them through a Technical Support case. 

Regards,

Gerardo

[matthieuremacle]

Dear Gerardo,

Thank you for your answer. 

Since I posted my previous message, I discovered an interesting thing:

When I add the line:

SIM->SCGC5 |= SIM_SCGC5_PORTB_MASK | SIM_SCGC5_PORTC_MASK; /* Ungate PORTB and PORTC clock*/‍‍‍

when configuring SPI connection to the modem, the previously heating processors stop heating and seem to have the expected behaviour. I just don't understand why...

Now, I have the following problem: Everything seems to work fine when 802.15.4 packets are received. The behaviour or the MCU is exactly as expected.

But when packets are emitted, things are more complicated. The packets are almost never received correctly, and when I touch the MCU (or the board near the MCU), it seems to enhance the amount of packets successfully emitted. This behaviour is totally unexpected because as already said earlier, the hardware I use is produced by a professional factory, they already produced thousands of boards with the MKW21 without problem and this behaviour here is observed on 1/3 of the MKW22 boards. It really seems to be llinked to the MCU itself...

Is there any registers inside the modem configuring the emission ? Perhaps an amplifier that does not work or something that is wrongly configured at boot.

I'm open to any suggestion, this problem is driving me crazy...

Best regards,

Matthieu.

[gerardo_rodriguez]

Hello Matthieu,

Since you are using custom software, I suggest that you try a simple application such as the SMAC connectivity test from the connectivity software in your boards and perform some TX/RX tests to see if the problem is software or hardware related.

You can refer to the Chapter 4 Kinetis Connectivity Test Application from the "ConnSw>\docs\wireless\SMAC\Kinetis SMAC Demo Applications User's Guide.pdf" document for information on how to use this application.

Regards,

Gerardo

[matthieuremacle]

Do you even read what I write ?!

How can I try this test application software with my custom hardware ? I must first have to adapt your source code to be compatible with my hardware but I don't even know where I can find it !

This MKW22 processor is the worst processor I ever used and be sure that I will never choose an NXP hardware for any of my future projects. 

I'm really upset and disappointed. I already lost 10+ days working on a problem that isn't even supposed to exist. The MKW21 and 22 are supposed to have THE SAME BEHAVIOUR !

So please give me helpful answers and not this formatted answer. 

1) Why does the line 

SIM->SCGC5 |= SIM_SCGC5_PORTB_MASK | SIM_SCGC5_PORTC_MASK; /* Ungate PORTB and PORTC clock*/

keeps my MCU from over heating ? What does it do exactly ? Could it have an impact on this 802.15.4 emission problem ?

2) Where can I find the source code of this application you're referring ?

3) Is there any errata of the reference manual for this processor ? Perhaps I could find some documentation in it that could help me but I didn't found any.

And for further programs to be downloaded, please note that I'm working on a Linux Environment so please stop providing me Windows stuff.

Matthieu.