What should I do with the JTAG pins in SiM3U1xx/SiM3C1xx devices? Should I use JTAG for debugging?
The ARM Cortex-M3 core is automatically in JTAG mode and the JTAGEN bit in the PBCFG module is set to 1 after a reset.
What to do with the pins if using JTAG:
The SiM3U1xx/SiM3C1xx TDO pin is not push-pull on a reset and does not automatically become push-pull. To use JTAG with SiM3U1xx/SiM3C1xx devices and the Silicon Labs Debug Adapter, the firmware on the device would have to set the TDO pin to push-pull. For an adapter with an adjustable clock, the Adapter can use a slower clock and a strong external pull-up on TDO to set TDO to push-pull and then switch to a faster clock for programming.
For future JTAG devices, the TDO pin will automatically become push-pull whenever the device needs to send data.
What to do with the pins if not using JTAG:
If the JTAG port isn’t used, the JTAG pins are always in open-drain mode after a reset, just like any other GPIO. The JTAGEN bit in PBCFG should always be cleared by firmware for “non-debugging” or release versions of code. For code that uses Serial Wire Viewer (SWV) for debugging, the JTAGEN bit must still be set for SiM3U1xx/SiM3C1xx devices.
These devices do not support boundary scan, so JTAG does not provide a debugging advantage over Serial Wire.
What happens if a High Drive Port Bank Bias is disabled?
The bias enable allows the High Drive pins to toggle; if the bias is off, the pins will hold their state with minimal current drawn from VIOHD. There will be no current drawn in this state if the PBLVMD bit is set to 1, which is only valid for VIOHD <= 3.6 V.
What does setting the lock word to something other than 0x0000_0000 or 0xFFFF_FFFF do? Can the device still be accessed externally?
Setting the lock word in Flash (address 0x1FFF_FFFC on SiM3U1xx/SiM3C1xx devices, for example) to a value other than 0x0000_0000 or 0xFFFF_FFFF will lock the device. A locked device cannot be accessed externally, but any code running in Flash or RAM will be able to run as normal.
To unlock a locked device, the lock word must be cleared by either:
Firmware running on the device writing the lock word to 0x0000_0000.
Erasing the device Flash externally. This can be accomplished using the command-line utility provided with AN678: Precision32™ si32FlashUtility Command-Line Programmer User's Guide. This application note is available on both the Application Notes webpage (www.silabs.com/32bit-appnotes) and the software webpage (www.silabs.com/32bit-software).
What does it mean that the USART/UART modules support IrDA and Smartcard? Do these features require the synchronous capability of the USART?
In IrDA mode, a 0 causes a low (or high) pulse for a configurable bit time (1/16, 1/8, 3/16, or 1/4). A 1 does not cause a pulse. The Smartcard support consists of the ability to capture or send a Smartcard ACK or NACK response during the stop bit periods.
Neither of these modes require the synchronous capability of the USART modules. As a result, all of the USART and UART modules have both IrDA and Smartcard support.
Embedded C++ can be practical for certain types of applications by restricting the implementation to a limited subset of C++'s capabilities, assuming a suitable compiler and sufficient memory is available. However, C++ is not always available and is often considered insufficiently maneuverable in tight spaces. This tends to encourage application developers to implement an object-like scheme in C, increasing the development and testing effort for the project. The si32Library object system reduces this effort by providing a uniform, reusable, object-oriented methodology for applications where C++ is inappropriate or unavailable.
Since si32Library is written in standard C, it will work across multiple compilers. The si32Library can also be used with C++ systems.
More information on the si32Library can be found in AN672: Precision32 si32Library Overview. The 32-bit Application Notes are available on the Silicon Labs website: www.silabs.com/32bit-appnotes
NVIC: the Nested Vectored Interrupt Controller manages all of the interrupts and exceptions on the Cortex-M3 device. This module is part of the system memory space at the top of the Cortex-M3 memory map.
Serial Wire: a two-pin programming port
Serial Wire Viewer: a debugging output pin associated with the Serial Wire programming port
Instrumentation Trace Macrocell (ITM): provides basic debugging information through the SWV output, including basic software trace, hardware trace, and time stamping. This is supported by the Silicon Labs Debug Adapter (10-pin CoreSight connector).
Embedded Trace Macrocell (ETM): detailed debugging information port with software trace and instruction activity decoding. ETM requires four high-speed pins and a high-end Debug Adapter, using the 20-pin CoreSight connector. This is not supported by the Silicon Labs Debug Adapter.
Can I execute code on my Cortex-M3 SiM3xxxx device from an external memory using the EMIF?
Yes, it is possible to do this. However, code execution from an external memory will be much slower than internal code execution because the bus accesses are slower and the core cannot take advantage of the Advanced High-Performance Bus (AHB) features.
Is it possible to differentiate between a power-on reset and a brown-out (supply monitor) reset?
Yes, it is possible to differentiate between a power-on reset and a brown-out reset on some devices.
Some devices have a separate power-on reset flag and VDD Monitor reset flag. If one of these flags is set, then all other flags in the register are of indeterminate value. However, these devices may have another flag in the PMU STATUS register that indicates whether the last reset was due to a power-on reset. This flag is independent of all other flags.
More information on reset sources and the available flags can be found in the device reference manual: www.silabs.com/32bit-mcu.
I purchased a 32-bit MCU kit and it came with a USB Debug Adapter with a different connector. Is this expected?
There are two types of USB Debug Adapters:
One set uses the 10-pin CoreSight debugging connector. This connector is much smaller (0.05' spacing) than the other USB Debug Adapter and has a slightly different pinout. These debug adapters also support Serial Wire for the 32-bit products.
The original USB Debug Adapter uses a shrouded and keyed 2x5 header with 0.10' spacing. These Debug Adapters work with the 8-bit products, but do not support the 32-bit MCUs.
More information on the CoreSight header and USB Debug Adapter connections for both types can be found in the Related Articles section.
Where can I find examples for the device peripherals?
The Software Development Kit (SDK) code examples provide examples for device peripherals. These examples use the HAL to access the device registers and are installed with the Precision32 software package from www.silabs.com/32bit-mcu.
More information on the code examples can be found in AN668: Precision32 Software Development Kit Code Examples Overview. Application notes and other 32-bit documentation can also be found at the link above.
A 32-bit platform with large memory enables a big and complex firmware system on the device. This complexity can slow development, as firmware consists of more layers with interweaving tasks and threads that are more difficult to create and debug.
The si32Library is a set of flexible, reusable, and portable source modules enabling core application level functionality for Silicon Labs 32-bit Precision32 MCUs. It includes facilities for debug logging, memory allocation, data collections, data transfers, and cooperative multitasking. The si32Library package is part of the Silicon Labs SDK and provides working abstractions of the hardware layer, reduces coding effort, and provides structure to aid and speed up toplayer application development.
More information on the si32Library can be found in AN672:Precision32 si32Library Overview. Application notes and other 32-bit documentation can be found here: www.silabs.com/32bit-mcu.
The Silicon Labs Hardware Access Layer (HAL) is an access layer for the SiM3xxxx device registers. The functions and macros are non-blocking and simple; they cannot return error codes, so they are designed to never fail. The HAL is designed to replace the individual bit field accesses of the module with a function name that describes the action the bit is controlling. HAL functions and macros are not designed to be thread-safe. These routines do not disable interrupts during nonmonotonic register modifications.
The HAL sits one layer above the hardware and is the only code that accesses the registers directly. More complex firmware systems like a Real Time Operating System (RTOS) or code example call the HAL and CMSIS routines.
More information on the HAL and the rest of the Silicon Labs SDK can be found in AN664: Precision32 CMSIS and HAL User's Guide. Application notes and other 32-bit documentation can be found here: www.silabs.com/32bit-mcu.
CMSIS is the Cortex Microcontroller Software Interface Standard defined by ARM. ARM provides this software package and specification for all ARM vendors. It is not an API specification; it’s an organizational and style standard.
The Silicon Labs Hardware Access Layer (HAL) is inspired by CMSIS. More information on the HAL and the rest of the Silicon Labs SDK can be found in AN664: Precision32 CMSIS and HAL User's Guide. Application notes and other 32-bit documentation can be found here: www.silabs.com/32bit-mcu.
I'm writing code to set up my peripheral, but nothing seems to happen. What am I doing wrong?
On SiM3xxxx devices, the low power oscillator (LPOSCn) is the default oscillator after a reset. In addition, the clocks to most peripherals are disabled to save power. The clock to the module must be enabled before firmware can modify the registers. The first initialization step in all peripheral initialization routines should enable the clock to the module.
More information on the clocking sources can be found in AN663: Precision32 MCU Family Clocking Options, the device data sheet, and the device reference manual. The 32-bit MCU application notes and device documentation can be found here: www.silabs.com/32bit-mcu.
More information on each of these clock sources can be found in AN663: Precision32 MCU Family Clocking Options, the SiM3C1xx data sheet, and the SiM3U1xx/SiM3C1xx reference manual. The 32-bit MCU application notes and device documentation can be found here: www.silabs.com/32bit-mcu.