K32W061/QN9090/JN5189 Overview of lessons learned

[ckielstra]

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.

[tcv_geo]

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?

[ckielstra]

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.

[ckielstra]

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.

[ckielstra]

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.

[ckielstra]

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).