Debug port

[butterfly]

Dear sir, dear missis,

I'm working with an STM32L053r8 on a step by step know-how. My interface with the bootloader runs fine, and I am able to cover the main features provided through this interface. The issues I try to cover now is the right understanding , how the Cortex M0+ runs at assembly level.  I done several tests without results today, I can continue to test with an iterative methodology; I can also use the debug port (SWD pin).

I developped an interface to do that, but at this time I didn't received any answer from the debug port. This one is built following Cortex architecture protocole (IHI0031G Debug interface architecture V5.2 architecture specification).

The only thing I can say, to define an hardware protocol at this level is a very important effort, and therefore I missed may be, some details. Or in short my best efforts, were insufficient to translate by hardware, this design document. What seems unclear to me is the specifications at the hardware level, my interface is supposed to work with V5.1 design, and I don't receive any debug interface ID, when I send the 0x85 command ( or 0xA5 command after parity checking) ?

This this surly bit & byte cooking, and maybe have you a more in depth debug port hardware specifications?

Many thanks for support you could provide; hoping this question isn't to deeply hardware?

Best regards.

Butterfly.

[S C]

Hello,

I don't see in your description the "Switching from JTAG to SWD operation" sequence described in chapter B5.2.2 of ARM IHI 0031E, required after target power on and between the reset and idle sequences. The STM32L053 does not implement the dormant state, you have to do this 16bits sequence before the setIdle sequence and DP_IDCODE read attempt. Your issue does not concern the way you read bits on your side as long as you don't see the ACK from the target on the line. It's currently rather the fact that the STM32L053 does not understand your SWD entry sequence; as I said previously, you may probe the one done by the ST-Link to compare (the ST-Link implements the ResetLine sequence with 53 pulses)

[butterfly]

Hello,

The dormant state is implemented with V5.2 debugger architecture and I use a V5.1, then I should be able to get an answer or an ack from the board. In order I reset the debugger with the "debug reset sequence" which is 50 clock pulses long as minimum, and I enter in iddle state with at minimum 2 clock pulses. From the iddle state I send the command to get the ID (code 0x85 or 0xA5 with parity bit checking).

Unfortunately I don't use ST-LINK, my desktop is a Mac, and if I well understood the software distribution for Nucleo packages, the main platform is PC. This is a fact, and I understand also thoses limitations.

Regards.

Butterfly

[S C]

The Nucleo also works on MacOS. Please read the chapter B5.2.2 of ARM IHI 0031E, you must send the value 0x79E7 (MSB first) somewhere in your init sequence. The sequence you describe is wrong, if your description is exhaustive.

[butterfly]

Following RM0367 page 956 I should read a device ID first with a value of 0x4417 for cat 3 or 0x4447 for cat 5; what is not clear to me is , how I should read this value?

Regards.

Butterfly.