topic K32W061/QN9090/JN5189 Overview of lessons learned in Wireless MCU

K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Thu, 20 Jun 2024 12:42:47 GMT

This isn't a question but a topic where I want to share info we learned when working on the K32W041 and that we want to share with other users. Please add more info in the answers to this thread so we all can learn.

1) There is a whole series of SOMs with the same core. Switching should be easy.
NXP acquired several manufacturers of wireless SOMs and is integrating those product lines into a series of SOMs with very different product numbers but an identical core and only differing in peripherals.
K32W041 / K32W061 Zigbee + Bluetooth, NFC for the K32W061. Formerly Freescale Kinetis
JN5188(T) / JN5189(T) Zigbee, NFC for the 'T' version. Formerly Jennic
QN9030(T) / QN9090(T) Bluetooth, NFC for the 'T' version.
These all have different datasheet documents, but the SDK is almost identical and suggest easy transition when desired.

2) First radio transmission is slow without temperature setting
Our device powers down very often, on waking up, the first (and often only) radio transmission took 80ms. Simply setting the temperature before calling the radio fixes this. Before the first radio transmission there is some calibration done, when the temperature is not set, this calibration takes way longer since no previous stored calibration value can be used.

3) RAM contents are corrupted after a reset
A hardware reset also resets the RAM voltage regulators, as a result, the RAM contents are destroyed after a hardware reset. This was unexpected and differs from many other processors. It makes it more difficult to have data survive a reset like in a firmware update. SDK 2.6.10 introduced the function RESET_ArmReset which resets fewer hardware modules and so retains RAM. All hardware resets, like watchdog and unhandled exceptions, still corrupt RAM.

4) ADC always references 3.60V
Not really a problem, but can have implications for your hardware design. We use a Lithium battery as power supply and the 3.65V of a new battery will be capped reported as 3.60V

5) Brown-out detection can't reset the chip
The brown-out detection can be configured to trigger an interrupt, but not to reset the chip.

6) Older models can provide missing documentation
The K32W041 SDK lacks documentation on how to use the IEEE 802.15.4 stack, luckily there is JN-UG-3024. Last updated in 2016, but still way better than nothing.

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Wed, 13 Dec 2023 15:16:14 GMT

7) Real Time Clock (RTC) resets on a hardware reset

This means that time tracking is lost after a watchdog reset, or other hardware induced reset (software called processor reset is fine).

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Wed, 24 Jul 2024 13:45:08 GMT

On reboot, the ROM code modifies RAM in the range 0x0400 7474 to 0x0400 7FFFF, i.e. the top 3kb in SRAM1 bank.

It's normal that the ROM code requires RAM stack space, but it would have been nice when this range was documented in the User Manual.

In our application we have some debugging data that we want to persist after a software reset. This worked like a charm, until a modification caused a change to the RAM layout, and then the data was garbled after a reset. It turned out that our NOINIT section overlapped the ROM-stack area. Now we know which data region to avoid, the solution was an easy change to the linker file.

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Thu, 15 Aug 2024 08:39:23 GMT

Documentation error in K32W061 User Manual, section 27.7.1, the section on software triggered ADC conversion
To avoid spurious ADC errors it says:

2. Set the trigger source to an unused setting using the SEQ_CTRL[TRIGGER] bits. The
value 3, for example, is not used on this device.

This is wrong since the value 3 is in use, see section 17.1.3 of the K32W061/K32W041 Register Manual, for the TRIGGER field (bit 17 to 12).
Not confirmed by NXP, but any value in the range 4 to 63 (6 bits field) seems good to me.

Note that the NXP example programs use values of 0 and 2. These are bad examples. These settings work for those examples as the connected hardware sources are not enabled, but for a generic example, it would have been better to use a value that can never create a conflict, i.e. any value in the range 4 to 63.

Re: K32W061/QN9090/JN5189 Overview of lessons learned

tcv_geo — Tue, 26 Nov 2024 15:54:30 GMT

I just found this thread. This is so useful thanks.

I had the exact same question as you (is trigger a mask or value) and saw your other thread with the meaningless responses from NXP. It looks like an AI bot rather than a person.

I have found so many bugs in the SDK for these parts, sometimes they fix them privately to my company, sometimes they fix them in the public SDK after many months, sometimes they just say this or that peripheral is deprecated don't use it. (eg: I found a bug in the WTIMER0 driver and they say only WTIMER1 is supported).

Do you have a github account so we can share fixes etc?

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Tue, 26 Nov 2024 23:03:34 GMT

Update to 1)
A big difference between K32W0x1 (Zigbee + Bluetooth), JN518x (Zigbee) and the QN90x0 (Bluetooth) is the ROM code. These NXP processors differ here from competitors since a large part of the driver software is present in 128kb ROM. This explains why there are three different product lines, these have different driver code for the targeted protocol. The use of ROM code has advantages like cost reduction (ROM is cheaper than Flash) and smaller OTAP size. A disadvantage is that it's more difficult to fix bugs or add new features.

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Thu, 21 Aug 2025 13:31:32 GMT

8 Power Saving: Don't activate the 32MHz crystal on each wake-up

The default code will enable the 32MHz crystal on each wake-up from power-down. This is nice because it saves some time when starting the Radio communications. But, in our application, we often wake up from power-down to read a sensor and then return to power-down again. We only do a Radio transmission once every 150 wake-ups and were able to save 0.6uA on average.

In the default code there is something like:

power_config.pm_config = pd_cfg.sleep_cfg | PM_CFG_XTAL32M_AUTOSTART;

We removed the AUTOSTART

And, when we enable the Radio, we added the following code:

CLOCK_SetXtal32M_LDO(); CLOCK_EnableClock(kCLOCK_Xtal32M); /* Enable the radio and restore the MAC settings. */ vAppApiRestoreMacSettings();

Note: we first had different code for enabling the Radio by calling vRadio_EnableXTALInit(), but in a few devices this failed to start the crystal (stuck in a loop waiting for the crystal to start).

Re: K32W061/QN9090/JN5189 Overview of lessons learned

ckielstra — Thu, 28 Aug 2025 08:55:47 GMT

9 Stuck on Radio crystal (32MHz)

When the radio oscillator is not running, the NXP 802.15.4 library will simply hang (timeout is missing).

We don't know if there is a more elegant way to detect this condition, but we use the watchdog timer. We set a flag before each operation and clear it afterwards, then if a watchdog timeout occurs with the flag set we know it is likely to be an issue with the radio library hanging, which could be an oscillator issue.