How does the Debug (Printf) Viewer work?
The Debug (Printf) Viewer uses the Serial Wire Viewer (SWV) block of the MCU core to communicate with the IDE. Specifically, the Serial Wire Output (SWO) pin is used. In order to successfully use the Debug (Printf) Viewer within the IDE, the following settings must be correct:
Configure in firmware:
1) Configure the SWO pin in push-pull output mode
Configure in Options for Target: To access these settings, right click project name in the project window tree and select “Options for Target …”. Next, select the 'Utilities' tab. Ensure that Silabs UDA Debugger is selected and click 'Settings'. Select the 'Trace' tab.
2) Enable Trace
3) Set the Core Clock Setting
See Application Note AN669 'Integrating Silicon Labs SiM3xxxx Devices into Keil UVision IDE' for detailed information on how to configure the Options for Target (steps 2 and 3 above). Application Notes can be found at https://www.silabs.com/documents/public/application-notes/AN669.pdf
Does Silicon Labs have a USB Communications Device Class example?
For EFM32 products, see AN0042: https://www.silabs.com/documents/public/application-notes/an0042-efm32-usb-uart-bootloader.pdf
For 32-bit SiM3xxx products, see AN758: http://www.silabs.com/Support%20Documents/TechnicalDocs/AN758.pdf
Silicon Labs does not currently provide example code for implementing a Communications Device Class on our 8-bit MCU's.
The following 8-bit USB examples are available:
-USBXpress - library version of bulk mode
-Standard bulk mode
-Standard interrupt mode
However, members of our community have implemented solutions for the 'F32x and 'F34x family of USB-enabled 8-bit MCUs. More information can be found here:
What happens when an interrupt occurs while the Flash is being written or erased by firmware?
During a Flash write or erase operation, the CPU is stalled and peripherals remain active, which is equivalent to Idle mode (the CPU behavior with the IDLE mode bit set in PCON.0).
Any interrupts which are posted during the Flash write or erase operation will be serviced in priority order once the Flash operation has completed.
To avoid a premature vectoring to an interrupt while MOVX write operations are targeting Flash memory, it is recommended to disable interrupts during the Flash write or erase, and then re-enable them after Flash writes have been disabled (by setting PSWE to a ‘0’). Once interrupts have been enabled, they will be serviced in priority order.
For more information and recommendations about writing and erasing Flash memory, please see AN201 and the Flash Corruption KB article, which is linked in the Related Articles section. Application Notes can be found on the Silicon Labs Application Notes website:
I have an MCU system and am having problems passing EMI specifications. Can you help?
We provide extensive guidance for EMI/EMC considerations in the Knowledge Base Article "Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC)", including links to additional in-depth EMI design resources.
I can't connect to my MCU, but I need to erase code space. How do I do this?
If an MCU's Flash has been locked, it may not be possible to press the IDE's 'Connect' button and establish an IDE connection with the MCU. In order to enable the IDE to connect to the MCU again, the MCU's lock byte must be reset, and the lock byte can be reset by erasing all of code space.
The IDE does not need to be connected to an MCU in order to erase all of code space. Before the IDE can erase code space, the user must check that:
* A debug adapter is connected to the MCU's debug interface
* This debug adapter is selected in the Connection Options window
* The MCU is powered
Once the three above conditions are met, the IDE can erase Flash contents by running Tools->Erase Code Space.
Are you planning on obsoleting any of your MCU products?
Many of our target applications and existing customers require a lengthy product lifespan with production for many years - ten years of production is not unusual for certain industrial customers. Our objective is to support these customers. Please see the following pages that describe our minimum longevity commitment for 32-bit MCU and Wireless MCU devices: