Clarification on the Micro STM32WLEJC and STM32WL55JCIx

Products & Technology
1

I am confused with the above two micro controllers, I have ported the code from github repository without noticing the above diffence, i came to know that i ported the code of STM55JC series and with changes it worked on the Wio-E5 mini module, now i have selected the micro STM32WLEJC in CubeMx and generated the code, i am getting compilation errors, i want to know how did the first porting worked as both are with different cores dual and single. How do i proceed should i make the code work for STM32WLEJC. Request your guidance.

2

Hi there,

So , Looks like apples and Half an Orange Mixing here :grin:

1. Why the Dual-Core Code (STM32WL55JC) Worked Originally

  • The Wio-E5 mini uses the STM32WLE5JC (single-core ARM Cortex-M4) microcontroller chip.

  • The STM32WL55JC is the dual-core variant (Cortex-M4 + Cortex-M0+) of the exact same MCU architecture.

  • ST designed the peripheral register maps, memory layouts, and radio hardware for both series to be almost identical on the Cortex-M4 side. When running dual-core example code that relies strictly on Core 0 (the Cortex-M4), it executes on the single-core STM32WLE5JC without throwing a hardware exception.

2. Why Generating STM32WLEJC Code in STM32CubeMX Breaks Compilation

When switching the project targeted device to STM32WLE5JC in STM32CubeMX:

  • Missing Inter-Processor Communication (IPCC) & Sub-GHz Middleware Flags: The dual-core STM32WL55 code uses specific dual-core IPC middleware (mbmux, STM32_WPAN, dual-core system init files).

  • Regenerated Board Support Files: CubeMX strips out or restructures the dual-core memory map headers and linker scripts when targeting a single-core WLE5 MCU, leaving orphaned function calls to nonexistent secondary core initialization routines.

How to Fix / Proceed

  1. Clean Code Generation for STM32WLE5JC:

    • In STM32CubeMX, select the target chip strictly as STM32WLE5JCIx (the exact MCU inside the Wio-E5).

    • Enable the SubGHz_Phy or LoRaWAN middleware under the Middleware and Software Packages menu using the single-core implementation.

    • Do not copy over old system startup or linker files from the STM32WL55 dual-core repository.

  2. Port Application Logic Only:

    • Keep the regenerated CubeMX HAL initialization and peripheral code for the WLE5JC.

    • Only copy the core user application logic (e.g., LoRa payload processing, sensor reads, state machine) from the old STM32WL55 project into the new main.c / application layer.

HTH
GL :slight_smile: PJ :v:

3

Thank you for reply, but it really looks very challenging, struggling with it for past couple of days.

4

Hi there,

So, I think you got luck y once the first time. But take it one step at a time
it’s a procedure.. so check the step and ask AI for some help on the specifics if you get worried. The target is what you need to be sure of, had it been the other way around you would have found out WAY :grin: faster..:crossed_fingers:

Read the wiki, make sure you are following that generally and you should get through it.
what is the end Game here, just an update or you building something?
HTH
GL :slight_smile: PJ :v:

5

The basic idea is to build the project with CubeMx and confirm the Tx and Rx. Once the project is successful, based on the customer requirements work only with Cube Mx for code generation for ADC and other peripherals and application code without distubing the Lora section, the development will then be faster that is the final goal.