Using an ARM MCU to flash another ARM MCU using JTAG, run diagnostic code, then flash again

Hardware
1

I’ve been working on automating the process of testing circuits for connectivity/functionality on some of my designs. My current process is as follows:

  1. Secure PCB into test jig.
  2. Manually flash test firmware, reboot and watch test jig lights come on to verify board was assembled correctly.
  3. Re-flash board with production firmware.
  4. Repeat.

I saw a video a while back about a fixture that incorporates another MCU to flash the board being tested and verify functionality with either a serial monitor or status LED to indicate a pass or fail. What’s had me hung up is I can’t figure out for the life of me how to flash an ARM chip with another ARM chip. Would there be an intermediary JTAG programmer? Can you bit-bang JTAG or SWD
functionality with something like a Teensy4.1 (600 MHz Cortex-M7)?

Thanks in advance for your insights.

2

download (2)

1 Like
3

Well, it heavily depends on the implementation. For example, with the Pi Pico, I use the PicoProbe firmware (flashed to Pico A, to debug Pico B) and OpenOCD to do GDB debugging of another Pico.

I’d assume a modified PicoProbe firmware could be designed to automate the deployment and testing of firmware.

1 Like
4

Not a particular helpful answer but:
It seems like you are trying to re-invent the wheel in developing a secondary arm board into a jtag programmer to test the primary arm board, why not just use a jtag programmer hooked up to the computer originating the code?

If you have a fancy ide you can even incorporate debug functionality into the programming of the mcu/board (via jtag) and get programming and verification done in one setup.

5

That picoprobe project is going to be a really good reference, thanks for the tip.

I hadn’t considered a raspberry pi, that might be a better choice just because of existing solutions like this.

6

Now that you mention it, that might be a much more practical solution. Software to automate flashing and then just communicate with an external board to verify I/O connectivity and such. Might even be able to scan for available Bluetooth devices to confirm that it’s broadcasting.

7

The pi Pico is great because its so damn inexpensive. Compare its $4 price point to the $20 arduino or teensy and its a no brainer.

8

Absolutely can be bit-banged if you control the clock. Many ST STM32 evaluation boards have an built-in ST-LINK programmer interface, which is guess what - another STM32 MCU. Just pre-programmed with USB-SWD bridge firmware.

The old versions of the STM32F4DISCOVERY manual (e.g. STM32F4-Discovery-USB-CDC/en.DM00039084.pdf at master · hobenkr88/STM32F4-Discovery-USB-CDC · GitHub page 32 - the diagram was removed in later versions) has a circuit diagram showing the MCU that handles the ST-LINK interface. They use GPIO pins for JTAG/SWD functions of the MCU being programmed:

ST-LINK interface
ST-LINK interface635×687 89.2 KB

Some of them even have a perforated PCB so you can literally snap-off the programmer interface: https://www.st.com/resource/en/user_manual/um1724-stm32-nucleo64-boards-mb1136-stmicroelectronics.pdf

9

I had no idea anything from raspberry pi was so inexpensive.

10

The Pi Pico is not a SBC like the Pi Zero. This is an arduino competitor obsoleter.

11

That’s cool, looks like the hardware side is straightforward enough. I think between that and existing implementations I might be able to pull this together.

12

I just looked at it’s specs, you weren’t kidding

1 Like
13

And check out the price point!

14

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.