Configuring K32 L2B OTA Updates over Cellular UART

K32 L2B OTA failures usually appear on the panel as an update that remains in download, reports a transfer failure, or restarts into the existing application. Start with NXP application note AN12649 as the device-side implementation reference. Treat the cellular download, UART transfer, image storage, validation, and activation as separate stages so one failure cannot be mistaken for another.

Read the symptom before changing code

Start here. Record the last completed update stage and check the cellular module diagnostics before touching flash or linker settings. A modem that never received the complete file cannot deliver a valid image to the K32 L2B.

Display or log distinct states for download, transfer, validation, activation, and startup confirmation. A single “OTA failed” indication throws away the information needed to find the failed layer.

Separate transport from installation

The cellular module is the network transport. The K32 L2B update component is the installer. Passing bytes over UART does not make those bytes executable and does not prove that the file is complete, authentic, or compatible.

A dependable flow has two control planes:

• The cellular side connects to the server, obtains the update file, and reports received length and transfer errors.
• The K32 L2B side frames incoming data, writes only to the update destination defined by the selected architecture, validates the finished image, records activation state, and transfers control through the approved startup path.

Keep the currently running application separate from any location being erased or programmed during reception. The exact storage arrangement, reserved regions, startup handoff, and linker boundaries must come from AN12649 and the memory configuration of your build. Do not copy addresses from a different device or example project.

Define the update contract from AN12649

Before writing the modem interface, turn AN12649 into an installation contract for the application, update component, and build system.

1. Identify the startup component responsible for selecting and launching an application image.
2. Record the permitted application and update-image regions from the selected project configuration and linker map.
3. Define the image metadata required by that implementation, including every field used for length, compatibility, integrity, authenticity, or activation.
4. Define the interrupted-update behavior. Loss of cellular service, power, or a processor reset must leave a deterministic startup choice.
5. Define how the new application confirms successful startup and how an unconfirmed image is handled.
6. Build the production image with the same memory assumptions used by the installer.

That is the design checkpoint. Do not begin flash writes until the generated image, linker map, reserved regions, and startup code agree. Changing only the application linker file wastes time when the installer uses a different layout or image format.

Transfer the image over UART

Make the UART link a framed transfer rather than an unbounded byte stream. The receiving application must distinguish control responses from firmware data, detect missing or duplicate blocks, and know the expected final length before activation.

1. Have the cellular module obtain the update metadata before the K32 L2B accepts image data.
2. Reject an image whose product or compatibility metadata does not match the target rules defined by the update design.
3. Prepare the update destination without erasing the running image or startup component.
4. Receive bounded blocks. Apply backpressure when the processor is erasing, programming, or validating data.
5. Confirm each accepted block only after the receiver has checked its framing and committed it to the intended destination.
6. Track the total committed length independently of the modem’s downloaded-byte count.
7. After the final block, compare the committed length with the declared image length and run the integrity and authenticity checks required by the update implementation.
8. Write activation state only after every validation step passes.

Size buffers and choose flow control from the actual modem output behavior and the K32 L2B receiver’s service rate. Measure overruns and framing errors under flash-programming load; an idle bench transfer does not test the critical condition.

Activate without losing recovery

Activation is a state transition, not merely a reset. Complete all pending writes, record the validated state through the mechanism selected from AN12649, and then enter the documented startup path.

Make every persistent state distinguishable: empty destination, partial image, complete but unvalidated image, validated image awaiting activation, and image awaiting startup confirmation. On restart, select behavior from that state instead of guessing from partially written data.

Never mark the new image active before validation. Never erase the known-good application merely because the modem reports a completed download. Those shortcuts turn a recoverable communications fault into a device-recovery job.

Verify the complete failure matrix

Test the release image through the same server, cellular module, UART path, and installation logic used in deployment.

1. Install a valid update and confirm that the expected application starts.
2. Read back the running application’s version or build identity through an application-level diagnostic.
3. Reset during the cellular download, during UART reception, during destination preparation, during programming, after validation, and during activation.
4. Disconnect and reconnect the cellular link at multiple transfer points.
5. Send a truncated image, a corrupted block, a repeated block, and an image rejected by the configured compatibility rules.
6. Force UART receive pressure while flash operations are active and check overrun, framing, retry, and duplicate-block counters.
7. Confirm that every failed case returns to a known startup state and never launches an incomplete image.
8. Repeat the update from the recovered state to prove that failure does not permanently block later updates.

Capture the last state transition, committed byte count, validation result, and reset reason in diagnostics that survive long enough to be retrieved. Without those values, repeated resets can hide whether the fault belongs to the modem, serial transport, flash operation, or startup decision.

FAQ