Custom Board Design with STM32L4 - Flash Programming and JTAG Questions

[Atilla Mete Turedi]

Posted on September 28, 2017 at 09:20

Dear Community,

I went through most of the application notes, the datasheet and the reference manual but since I am a hardware guy, I want to make sure that I understand things correctly before I start the design. I am consent with basic yes/no confirmations from people with experience.

1. I can program a bare metal MCU using the 10-pin JTAG connector alone.

2. I can use the IAR EWARM + Segger J-Link Pro combination for debug and flash programming.

3. I can set all JTAG pins (PA13, PA14, PA15, PB3 and PB4) to their alternate functions.

4. Each time the MCU is reset, even if JTAG was previously disabled by the application program, all JTAG pins are set back to JTAG functionality and JTAG is enabled.

I just want to make sure that, I can use JTAG and only JTAG for flash programming of the MCU and my application program can use all the pins used by JTAG as GPIOs. 

And more thing, this might sound dumb but none of the alternate functions are actually named 'GPIO' in the datasheet. How do I set them as just basic GPIO and not one of the alternate functions?

Best Regards,

Mete

#stm32 #iar #gpio #jtag #ewarm #stm32l4

[Atilla Mete Turedi]

Posted on October 04, 2017 at 09:28

Can anyone help with this please?

[AvaTar · Accepted solution]

Posted on October 04, 2017 at 10:21

Can anyone help with this please?

Sure, albeit I'm no hardware guy.

1. I can program a bare metal MCU using the 10-pin JTAG connector alone.

Yes, in theory.

Practically, it is highly recommended to make provisions to set the BOOT0/BOOT1 pins to defined states during startup.

Jumper would be good.

During development, you might need to start into the system bootloader, which requires this pins.

2. I can use the IAR EWARM + Segger J-Link Pro combination for debug and flash programming.

Yes, I have used this combination commercially (with Base instead of Pro version).

3. I can set all JTAG pins (PA13, PA14, PA15, PB3 and PB4) to their alternate functions.

Yes, but software guy will not love you for that.

Experiences show that saved HW costs are 'overcompensated' through more complicated and prolonged development and debugging / error tracing with field returns.

4. Each time the MCU is reset, even if JTAG was previously disabled by the application program, all JTAG pins are set back to JTAG functionality and JTAG is enabled.

Correct, if you do not enable the 'Readout Protection' feature. This would, depending on the level, disable JTAG all together.

Make sure that the alternate functionality does not require hardware/components on those pins that interfere with JTAG functionality.

There are several application notes about this topic (JTAG, Bootloader, boot modes, etc.).

I suggest to discuss this topics with your SW colleagues, and check their requirements.

[waclawek.jan]

Posted on October 04, 2017 at 11:24

We are using SWD (that's just 2 signals and GND in basic setup instead of 4 of JTAG) plus reset where the pins are shared.

Where the pins are shared, it's good to assign very simple functionality to these, so that they could be handled with minimal debugging, and are not necessary during the main course of programming/debugging.

---

The other question - in GPIO there are 2 registers for setting up the behaviour - MODER selects between GPIO In, GPIO Out, Alternate Function and Analog (the 'F1 family is slightly different as it's the oldest family and this detail was not very well designed there). Only if Alternate Function is selected for a pin in MODER, the selection of function through AFRL/AFRH is valid.

JW

[Atilla Mete Turedi]

Posted on October 04, 2017 at 12:29

Thank you both for your detailed answers!

Dear

meyer.frank

Yes, in theory.

Practically, it is highly recommended to make provisions to set the BOOT0/BOOT1 pins to defined states during startup.

Jumper would be good.

During development, you might need to start into the system bootloader, which requires this pins.

Why in theory? I can add a switch to select the boot state of BOOT0 pin but as far as I am concerned that is all I can manage with a bare metal MCU.

Yes, I have used this combination commercially (with Base instead of Pro version).

Answer appreciated.

Yes, but software guy will not love you for that.

Experiences show that saved HW costs are 'overcompensated' through more complicated and prolonged development and debugging / error tracing with field returns.

Well the problem is, I have to use both SAI sub-blocks andit sadly conflicts with JTAG pins, It does not however conflict with SWD so I might use that instead during debug as

Waclawek.Jan

kindly put it.

HW and SW guys will never love each other anyway...

Correct, if you do not enable the 'Readout Protection' feature. This would, depending on the level, disable JTAG all together.

Make sure that the alternate functionality does not require hardware/components on those pins that interfere with JTAG functionality.

There are several application notes about this topic (JTAG, Bootloader, boot modes, etc.).

I suggest to discuss this topics with your SW colleagues, and check their requirements.

I will not be using the Readout Protection in early development stages I believe. However I cannot make sure that alternate functionality does not require the hardware on these pins because of what I said a paragraph above. Why I am concerned about this is the constant flashing during the development period using JTAG.

Dear

Waclawek.Jan

,

We are using SWD (that's just 2 signals and GND in basic setup instead of 4 of JTAG) plus reset where the pins are shared.

Where the pins are shared, it's good to assign very simple functionality to these, so that they could be handled with minimal debugging, and are not necessary during the main course of programming/debugging.

I have never used SWD for debug before but I don't see why I should not do that.

The other question - in GPIO there are 2 registers for setting up the behaviour - MODER selects between GPIO In, GPIO Out, Alternate Function and Analog (the 'F1 family is slightly different as it's the oldest family and this detail was not very well designed there). Only if Alternate Function is selected for a pin in MODER, the selection of function through AFRL/AFRH is valid.

Crystal clear explanation that deserves RM occurrence.

Regards,

Mete

[AvaTar]

Posted on October 04, 2017 at 13:57

Why in theory? I can add a switch to select the boot state of BOOT0 pin but as far as I am concerned that is all I can manage with a bare metal MCU.

In theory because with an uncooperative application, you (or colleagues) will have trouble to access the chip with JTAG/SWD alone.

The system bootloader uses other channels than JTAG for communication (UART, USB, ...).

Well the problem is, I have to use both SAI sub-blocks andit sadly conflicts with JTAG pins, It does not however conflict with SWD so I might use that instead during debug as

Waclawek.Jan

kindly put it.

This is fine IMHO.

I used 'JTAG' as general term for JTAG/SWD, i.e. 'debug access'.

SWD is fine, too. Cortex M0 devices support SWD only.

However I cannot make sure that alternate functionality does not require the hardware on these pins because of what I said a paragraph above.

Debug access often speeds up development, and is of great advantage for error tracing.

SW guys will probably insist, but one can live without.

An alternative output channel for instrumentation/tracing, like UART/SPI, will be helpful as well.

Why I am concerned about this is the constant flashing during the development period using JTAG

Under normal circumstances, the debugger will 'catch' the MCU after reset, and be able to erase/program the Flash.

But as soon as the running application reassigns the debug pins, debug connection is lost.

Re-flashing during runtime is then impossible without connected reset line.

[Atilla Mete Turedi]

Posted on October 04, 2017 at 15:20

In theory because with an uncooperative application, you (or colleagues) will have trouble to access the chip with JTAG/SWD alone.

The system bootloader uses other channels than JTAG for communication (UART, USB, ...).

Understood. I will make sure UART/USB ara available to the outside world as well.

This is fine IMHO.

I used 'JTAG' as general term for JTAG/SWD, i.e. 'debug access'.

SWD is fine, too. Cortex M0 devices support SWD only.

Cool.

Debug access often speeds up development, and is of great advantage for error tracing.

SW guys will probably insist, but one can live without.

An alternative output channel for instrumentation/tracing, like UART/SPI, will be helpful as well.

Perhaps an FTDI on one of the UARTS will help debugging.

Under normal circumstances, the debugger will 'catch' the MCU after reset, and be able to erase/program the Flash.

But as soon as the running application reassigns the debug pins, debug connection is lost.

Re-flashing during runtime is then impossible without connected reset line.

Let us pray for normal circumstances then.

Thank you again for your kind answers.

Regards,

Mete