Debug Options on C091 Custom Board

[chisatholm]

I made a custom board using a C091KCT6. I assumed I would be able to figure out a way to display data in real time using printf. Unfortunately, I did not make provision to expose PA2 and PA3 (or indeed any pins other than the ones used by my board). PA2 is in any case in use as SPI1 MOSI. So I have pretty much accepted that I need to make a new custom board, and I am keen to ensure that I will be able to use printf this time!

I believe that two good solutions are to buy the STLINKV3-SET and either a) re-design the board to expose the PA2 / PA3 UART to that ST-LINK or b) re-design the board with an MCU that has a SWO pin and expose that to the STLINK-V3.

I would like two kinds of help, please: if I do not need to buy a new debugger or re-design the board, it would be great to hear how I can use printf with the setup I have, or avoid one of i) buying a new debugger and ii) re-designing the board.

If I do need to buy a new de-bugger and re-design the board, it would be great to have confirmation that both a) and b) above are options for me.

I have seven ST-LINK options available to me, one standalone and 6 dev kits:

 

Board	ST-LINK type
Nucleo-C092RC	ST-LINK/V2EC
STM32VLDISCOVERY	ST_LINK/V1
STM32F407G-DISC1	ST-LINK/V2-A
Nucleo-H753ZI	STLINK-V3E
Nucleo-C031C6	ST-LINK/V2-1
STM32F4-DISCOVERY	ST-LINK/V2-A
NA	standalone ST-LINK V2

I believe that none of these options is suitable (I would love it if someone can persuade me I'm wrong, of course). The promising ones are the V2-1 and V3E ST-LINKs, but in order to use these I would need either i) to expose the SWO pin of the C091KCT6, or ii) connect PA2 & PA3 on the C091KCT6 to the ST-LINK/V2-1 or ST-LINK/V3E.

Option i) doesn't work because, I think, there is no SWO pin on the C091KCT6.

Option ii) doesn't work because, I think, there is no provision for connecting UART pins to the ST-LINKs ON THE BOARDS from a custom board, only from the MCU on the dev kit board.

If I get the STLINKV3-SET, then I can either connect PA2 & PA3 of the C091KCT6 to it (and do my SPI stuff elsewhere on the chip) or replace the C091KCT6 with a chip that has a SWO pin. (I am not concerned about BoM cost, this is a low volume project. But I am concerned about the cost of buying a J-link :) ).

I think I need printf specifically - I am driving a mechanical oscillator close to its resonant frequency, so I need the whole system to run without interruption in order to be able to assess how well the control system is functioning. So breakpoints are great, but the oscillation will die each time I halt execution.

Thanks for reading, apologies for the newbie questions and the long post!

[TDK]

Consider sending printf messages over UART. Less complicated, doesn't require debugger configuration. Most recent debuggers have a UART channel dedicated for this.

[Pavel A.]

For a custom board do yourself a favor, buy a new ST-Link V3 MINIE. Do not hack the Nucleos.  As TDK advised it has internal TTL UART to USB converter to use with STM32 UARTs. You won't use SWO because STM32C0 does not have it.

[chisatholm]

Thanks so much for your reply. Do you favour MINIE over V3SET because of the difference in price? 

[Pavel A.]

@chisatholm I favour MINIE because have used in in several projects, it has two convenient connectors and just is a great value for the price.

 

> one option could be to record historical data in a ring buffer 

Segger and Keil (at least these two) have a software library that stores trace logs (text or binary) in RAM buffer. Their debuggers are aware of this, they periodically move the trace data out of the buffer and display it. This works even without SWO.

 

[Tesla DeLorean]

SWO not supported by Cortex-M0(+) parts

USART2 is exposed via SWDIO/SWCLK pins, so could have serial output independently of debugger

Also you use a ring-buffer in memory for data output that you could inspect in the debugger

PA14 USART2_TX (and RX option), PA13 USART2_RX

[chisatholm]

Thanks for your reply. Great to have confirmation that SWO isn't there.

Can I just check my understanding of the rest of your reply?

I think you're saying one option could be to record historical data in a ring buffer with my current setup (no new board or debugger) and then interrogate that data by inserting a break point. It brings the mechanical oscillator to a halt each time, but at least I get to see what was happening.

Another option would be to bring data out on PA13 and PA14. This is very attractive of course, since it would mean real time data without redesigning the board. But I'm using these pins to flash the code already, so I don't see how I can also use them as USART2. If I had the USART2 available, would I then use a board based on eg FT232, CP2102, or CH340 as the interface to my laptop?

[Tesla DeLorean]

After the board is up you can determine if the debugger is attached and then potentially transition to a USART2 TX output stream, which you could tap. This shouldn't preclude you using it as a means of flashing the device. Say you also connect NRST and use "connect under reset method" or delay the usage transition somewhat. Perhaps gate operations via a memory variable or other GPIO state that you can accommodate in the design as is.

Depending on the debugger you can use a portion of memory as a view port as to what's going on without break pointing and stopping things on human terms.