Enabling PAL subsystem freezes system and JTAG

[datenwolf]

Hi,

I'm at a loss here, after I spent an unsuccessful evening, trying to get a STM32F207 to work on a custom board. The code and board are based on the Olimex STM32-E407, with a few exceptions: The external crystal resonator is a 16 MHz one instead of 12 MHz and certain pins have different connections. However Ethernet and SD-Card are identical to the Olimex board. Also later the EBI will be used, connected to a FPGA crossbar on a (not yet connected) mezzanine board.

So here's my problem: When starting my ChibiOS based image the system will freeze as soon as the PAL configuration is performed. First I suspected to have an error in the clock programming, but as it turns out the PAL still succeeds to route MCO1 to its output pin, MCO1 itself being routed to SYSCLK. The output shows a nice 120 MHz signal.

In addition to the system being frozen also JTAG ceases to work; you can't even "reset halt" the system to reprogram it. The only way to get the system in a programmable state is by setting the BOOT0 and BOOT1 pin to system memory.

If I disable the PAL subsystem in halconfig.h it will nicely enter and run the main program, I can attach a debugger via JTAG and watch it, but without access to the outside world it's rather useless.

So what kind of PAL / port configuration could have this effect?

[Tectu]

Try to set HAL_USE_MAC in your halconf.h to FALSE for a try. What you describes happens for example, when the MAC HAL does get initialized but no PHY could have been found.


~ Tectu

[datenwolf]

Thanks. I'll try that tomorrow, when I'm back in the lab.

[Giovanni]

Hi,

Probably in your board.h you change the state of the JTAG-related pins, this is why it freezes during initialization, make sure to leave all the JTAG-related pins to their reset state as described in the reference manual.

Giovanni

[datenwolf]

Hi,

Probably in your board.h you change the state of the JTAG-related pins, this is why it freezes during initialization, make sure to leave all the JTAG-related pins to their reset state as described in the reference manual.

Giovanni

I take you mean the reference manual of the microcontroller used. I'll try that although I derived my board.h from the Olimex STM32-E407 board.h. Can I somewhere retrieve a reference board.h for a STM32F207IG with the right settings for the JTAG pins present?

What Tectu suggested…

Try to set HAL_USE_MAC in your halconf.h to FALSE for a try. What you describes happens for example, when the MAC HAL does get initialized but no PHY could have been found.
~ Tectu

did not help at all.

[Giovanni]

Hi,

I don't have a board file for your micro.

The board.h from the E407 already configures the JTAG pins correctly, unless you changed some settings it should work. Verify the settings of:

Code: Select all

 * PA13 - JTAG_TMS                  (alternate 0).
 * PA14 - JTAG_TCK                  (alternate 0).
 * PA15 - JTAG_TDI                  (alternate 0).

 * PB3  - JTAG_TDO                  (alternate 0).
 * PB4  - JTAG_TRST                 (alternate 0).

In the RM under the GPIO section there are the reset values for those pins.

Giovanni

[datenwolf]

In the meantime I got a bit further, too. The PCB designer connected SPI1_MISO/MOSI to PB4/5 of which PB4 is also JTAG_TRST. I did configure PB4 as SPI AF=5, and that freezes the system. If I configure for JTAG AF=0 with Pull-Up then I get past the PAL configuration…

*EDIT* It would be nice to know, why using SPI alternate function on PB4/5 interferes with JTAG, maybe something in the order of GPIO configuration register manipulation.

Now it crashes somewhere in SDIO configuration, which I know because I finally can JTAG the thing…

[Giovanni]

Hi,

If you debug using SWD instead of JTAG then you only need PA13, PA14 and PB3 saving two pins, including PB4. You need an SWD-able debugger like the ST-Link.

Giovanni

[datenwolf]

Technically it should be possible to use JTAG without TRST. Also I'm currently using the JTAG without TRST on this board. Though it might of course be, that the STM32 imposes certain constraints on the combination of AF bits being set.

So in the meantime I'm not using the SPI on this board, it's reserved for future use anyway. Also I now ran in the situation described by Tectu; I'll get to that later.

I consider the issue solved for now, as I get the programm running toward the event loop and have two LEDs blinking. Next step: Getting the external memory bus and a display attached to it working.

[Tectu]

Good to hear that you could "solve" your issue


~ Tectu