For some projects it is not possible to have the device under debug available on my desk: the board might be in another room, on another site or in a place where physical access is not possible or even dangerous. In that case an IP-based debug probe (see Debugging ARM Cores with IP based Debug Probes and Eclipse) is very useful: as long as I can access its IP address, that works fine. It is an excellent solution even if the board is moving or rotating: hook it up to a WLAN access point and I still can use it as it would be on my desk.
It is a common thing to boot a Linux system (see the Raspberry Pi) from a micro SD card. It is not that common for a microcontroller. The NXP i.MX RT ARM Cortex-M7 fills that gap between these two worlds. No surprise that it features a ROM bootloader which can boot from a micro SD card.
Booting from a SD card is kind of cool: load a new software to the card, insert it and boot from it. In some applications this can be very useful: in my configuration the processor starts the ROM bootloader, then loads the image from the SD card into RAM and then runs it. In that configuration no internal or external FLASH memory would be needed.
In previous blog posts, I have described how an FTDI USB device can be programmed in Python to access the SWD bus of an ARM microprocessor. This allows the internals of the CPU to be accessed, without disrupting the currently running program.
In this blog I take the process one step further, and add a graphical front-end, that shows the CPU activity in real time
Working with low power modes can be challenging. It can severely affect debugging capabilities of a microprocessor or microcontroller. I ported a FreeRTOS application using the Tickless Idle Mode to the NXP i.MX RT1064 board, and all of a sudden, the board was unresponsive to any debugger connection. Luckily the board was not really bricked, but it took me while to find a way to recover it. So for when you end up in a situation with a ‘bricked’ i.MX RT1064 board, this article might be helpful for you to recover it.
A small ARM developmentboard from SMDprutser, that is available on GitHub:
Searching the prerequisite Chinese websites to satisfy my shopping fetish I came across a neat little ARM Cortex-M0 chip which is an extremely good bang for buck. I believe it is the smallest chip available in a reasonable hand-solderable package (TSOP8). This board gives you everything to explore this marvel of this Chinese Semiconductor.
As my final installment for the posts about my LED Wristwatch project I wanted to write about the self-programming bootloader I made for an STM32L052 and describe how it works. So far it has shown itself to be fairly robust and I haven’t had to get out my STLink to reprogram the watch for quite some time.
The main object of this bootloader is to facilitate reprogramming of the device without requiring a external programmer.
Sjaak writes, “This is part 4 in the series where we compare the STM32F103 with its Chinese counterpart the GD32F103. Both are ARM Cortex M3 microcontrollers which are mostly pin, peripheral and register compatible. Now we compare the SPI master peripheral of both chips.”
Murata produces LoRa module CMWX1ZZABZ-xxx based on SX1276 transceiver and STM32L072CZ microcontroller. The soldering of the LGA module is not very hobby-friendly. I constructed small breakout PCB for this module with additional buck/boost switcher and place for SMA connector. The transceiver features the LoRa®long-range modem, providing ultra-long-range spread spectrum communication and high interference immunity, minimizing current consumption. Since CMWX1ZZABZ-091 is an “open” module, it is possible to access all STM32L072 peripherals such as ADC, 16-bit timer, LP-UART, I2C, SPI and USB 2.0 FS (supporting BCD and LPM), which are not used internally by SX1276.
Here’s the part 3 of Sjaak’s post comparing the GD32 to the STM32:
Since the GD32F103 can run as fast as 108MHz but has not a proper USB clock divider to provide a 48MHz clock for USB communication we need another way to communicate with the outside world. Since the early days of computing the easiest way to go is a asynchronous serial interface using the UART peripheral. I can try to explain how this protocol works, but here is a better write-up.
The defacto ‘hello world’ for microcontrollers is blink a LED at a steady rate. This is exactly what I’m going to do today. I made a small 5×5 development board, soldered it up and started programming. In this first example we not gonna use fancy IRQs or timers to blink at a steady rate, but we insert NOPsas delay. This would give an idea of the RAW performance of the chip. The used code is simple; set up the maximum available clock available and then toggle RA0 for ever.