Microcontroller FAQs

Microcontroller Frequently Asked Questions

Try ..

  • Check pins BOOT[1:0] = "01" for enabled boot from system memory.

  • Check if your target is affected by errata 2.13 and do the required settings (see STM32F105xx and STM32F107xx Errata sheet).

  • If that target is connected via USB and the device is recognized by the host PC it is possible that the DFU gets activated instead of ASC/CAN boot loader. In that case you either have to disconnect USB or make sure that USB is not recognized by host PC, e.g. by pulling PA11 or PA12 to ground.

  • When using STM3220g-EVAL board make sure that J31 is open to prevent pin PB11 getting Low. When using CAN bootstrap loader make sure J3 and J10 are set properly to CAN2.

These are ..

  • Full context
    Otherwise the unsaved registers cannot be restored after a channel break (breakpoint or step), the unsaved registers will have an undefined contents the debugger is not prepared for other than full context
  • PCP_CS.RCP must be 0 (channel start from context)
    Otherwise the channel starts from the channel entry point (0xF002000 + 4 * priority) rather than from the location where the program was broken (stepping would not be possible). The register R7 must be set correctly in the PRAM in the user program example (Tasking):

  .sdecl "pcp.context", DATA
  .sect "pcp.context"
  .space 32
  Ch1: .word 0x00020040 ;R7 begin address 0x2, channel enabled
  .word 0x0 ;R6
  .word 0x0 ;R5
  .word 0x0 ;R4
  .word 0x0 ;R3
  .word 0x0 ;R2
  .word 0x0 ;R1
  .word 0x0 ;R0

  • Channel must be enabled
    Disabling the channel is an indicator that a debug instruction was executed. Together with PCP_ES the idle state of the channel is interpreted as running or halted.
  • Shared code is not debugable
    Otherwise the debugger gets confused, (UDE is not a multi thread debugger yet)
  • Only one channel may be debugged at a time
    If one channel is broken and a second channel is invoked and the second channel runs also into a break, then the debugger gets confused
  • Error handler for pcp errors must exist in the TriCore program (only for TC1.2 Derivates TC1775)
    Only necessary if the channel that is being debugged can be invoked while the program is at an breakpoint. (i.e. a timer invokes the channel while the user steps thru the channel code) the TriCore must run to handle the error interrupts coming from the PCP

    Example for an error handler (Tasking):

  #define PCPERRSR 3

  void _interrupt(PCPERRSR) PcpErrSr (void)
  {
  }


  void main ()
  {
  PCPCS = 0x00000021 | PCPERRSR << 24;
  }

That behavior occurs due to the nature of implementing software breakpoints on the PPC440.

The kernel debugger uses the TRAP instruction to patch software breakpoints. The application debugger does it in the same way. It is a typical resource problem. To avoid that problem it is possible to prevent the kernel debugger from setting/using TRAP breakpoint patching via the Jtag Target Interface setup. Enable the Do not use TRAP for software breakpoints option in the PowerPC 440 page via UDE menu Config -> Target Interface. Be aware that is only possible to use hardware breakpoints with that option enabled.

That happens typically when some registers are not initialized before using, e.g. the 64bit general purpose register for spe instructions. after reset these registers will have random content on both cores. if that register are used that could result in different results on both cores which will raise a lockstep error.

To avoid such problems do an initialization off all registers and CPU resources before using.

Dual processor mode and lockstep mode is configured inside the Shadow Flash ..

The actual state could be observed using the SSCM User Option Status Register (UOPS). The mode could be switched using address 0x0020_3E18 in the Shadow flash. Bit 0x0040_0000 has to be set for LSM and cleared for DPM mode.

For switching mode with UDE connect to the target using the actual mode. Activate the Shadow flash and clear the Automatic sector erase before program and activate the Simulate Random Access mode option. Open a memory window and go to address 0x0020_3E18. Change bit 0x0040_0000 and open Memtool and execute program.

After you have disconnected and repowered the target, the new mode will be active.

Dual processor mode and lockstep mode is configured inside the Shadow Flash ..

The actual state could be observed using the SSCM User Option Status Register (UOPS). The mode could be switched using address 0x00FF_FE10 in the Shadow flash. Bit 0x0040_0000 has to be set for LSM and cleared for DPM mode.

For switching mode with UDE connect to the target using the actual mode. Activate the Shadow flash and clear the Automatic sector erase before program and activate the Simulate Random Access mode option. Open a memory window and go to address 0x00FF_FE10. Change bit 0x0040_0000 and open Memtool and execute program.

After you have disconnected and repowered the target, the new mode will be active.

Flash programming via UDE Memtool is only possible via master core 'z1'.

So even the *.elf file for the 'z0' core must be flashed via 'z1' core. The best method for doing so is following step-by-step guide:

  1. Download and flash the *.elf file for 'z0' via 'z1' Debugger
  2. Download and flash the *.elf file for 'z1' via 'z1' Debugger
  3. Enable Attach to service mode in debugger properties for 'z0'. Go to menu Config - Debug server configuration and select Download in the Debug server section. Enable the option.
  4. Download symbols for 'z0' via 'z0' debugger in Service mode

The elf file patterns are loaded now into the flash via 'z1' core and the symbols are loaded in each according debugger.

Command Sequence ..

  • Create a new workspace usind the default cfg-File for multicore debugging (NXP MPC5510EVB Evalboard with MPC5517E (Jtag/Multi Core debug z0 and z1/VLE)), make sure both cores are enabled.
  • Enable Flash-Programming in Controller0.z1
    (status line should display Controller0.z1, if not, doulbe click the status line)
    • (Controller0.z1)Tools->Flash Programming...->Check Enable 1MByte OnChip PFLASH
    • Set Random Access mode using Setup...->Program->Simulate Random Access Mode
      (this is needed to program code of z0 and z1 seperatly into the flash)
    • Exit
  • Download application for z0 in Controller0.z1 (because z0 cant do flash programming both applications for z0 in z1 have to be programmed into Controller0.z1)
    • (Controller0.z1)File->Load Program...
    • in the appearing dialog box push Program..., exit
  • Download application for z1 in Controller0.z1
    • (Controller0.z1)File->Load Program...
    • in the appearing dialog box push Program..., exit
  • Load Symbols of application for z0 into Controller.z0
    • (Controller0.z0)Config->Debug Server Configuration->Debug Server Download->Attach to ServiceMonitor
    • (Controller0.z0)File->Load Program...
  • Now the applications of both cores are loaded and can be debugged sepeartly.
As soon as z0 is enabled by z1 a new program window Controller0.z0 appears and shows the entry point of the application for z0.

Probably you flashed a wrong checksum to reserved vector location 7 (Offset 0x1C).

The bootcode does not start your application if the checkksum is invalid. The checksum is simply the twos complement of all DWORDs before.

Solution: Either set a valid checksum in your startup code area or use UDE's build in checksum driver:

  1. Open Memtool Dialog
  2. Press Setup, go to driver card
  3. Select Use standard FLASH-Driver from library and Press ...
  4. Select driver with automatic checksum calculcation from defaults

What is to be followed?

Boot Mode P10.0 P10.1 P10.2 P10.3 TRST XC2000 TRST XC2000M XC2000N XC2000H
ASC-BSL 0 1 1 1 don't care 1
JTAG Reset*  1 1 1 1 controlled by UAD(2) controlled by UAD(2)
JTAG Service**  1 1 1 1 1 1
DAP Reset*  0 0 1 1 not available controlled by UAD(2)
JTAG Service**  0 0 1 1 not available 1

* JTAG Reset/DAP Reset - Program execution does not start after reset
** JTAG Service/DAP Service - Program execution start after reset

Main differences: TRST must be held high for XC2000M, XC2000N, XC2000H to start bootstrap loader, in other case processor start to run from internal FLASH memory. The state of TRST is don't care for older XC2000.

Install the latest UDE version ...

  1. Use a default cfg file or create cfg File with MPC5516
  2. Set 'z0' Core to be connected with 'Keep application running'
  3. Set 'z0' Debugger to service mode
  4. Load and download elf File via 'Z1' Core Debugger
  5. Load same elf file into 'z0' Debugger