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.

[STea]

Hello @butterfly ,

I'm sorry but I don't seem to get your request and your issue description as well clearly.

can you please explain what you are trying to do with the STM32L0 and what is your problem, is it related to bootloader or debug access throw SWD or JTAG, this will give us the necessary information to identify your problem correctly.

Regards 

[butterfly]

Thanks to answer.

Concern of my question is the debugger in SWD mode.

 

Thanks

Butterfly

[STea]

Hello @butterfly ,

what is the exact problem with the SWD interface?

are you using and STM32 Nucleo or discovery board or is it a custom board?

are you able to connect to it with CubeProgrammer ?

are setting the SWIO and SWCLK pins as input for another usage for example?

Regards 

 

[butterfly]

Dear sir,

The answers to yours questions are in my first email. SWIO and SWCLK are connected to a hardware from my own in the goal to exchange informations from the debugger. Thoses pin being dedicated to debug, there is no need to start with Cube Programmer.

Regards.

[STea]

Hello @butterfly ,

how is your hardware is initiating the debug session?

in case of the usage of the microcontroller win one of our development boards this is being handling via the embedded STlink which is another microcontroller connected to the debug pins here is a snippet of the schematics for NUCLEO-L053R8 for reference :

The hardware you are using to initiate a debug session and the way you are doing it is quite unknown for me, and, after checking there is no identified problems with debug interface for this microcontroller. 

Regards

 

[butterfly]

Hi.

Thanks to advice me with a detail of the MB1136 mother board. This detail show how the SWDIO and SWCL are tied to PA13 and PA14 of the MCU for debug.

I am connected directly on PA13 and PA14, with jumpers on CN2 out. 

I'm enjoyed the debugger runs well with ST-LINK and ST Softwares Partners Packages. Then my question in short is do you provide timing diagrams of this interface, as you describe it in RM0367 page 954.

My hardware connected to the MCU's pin, doesn't get any ACK signal from the MCU. En exemple of timing chart could allow to check if bit transferts are right tuned?

In addition I attach a short list with complet ship ID of the microcontroller soldered on this board.

Regards.

 

package release: 1.1
Chip ID: 1047
Flash size: 64 Ko.
Waffer number: 16
Lot number: G236483
SignID: 4980806

[butterfly]

Hi, happy new year,

I didn't get any answer about debugger timing diagrams following my last e-mail. Do you expect I can wait for some details, or may be this isn't in the scope of the support team?

Thanks in advance for your answer.

Regards.

Butterfly.

[S C]

Hello,

my understanding is that you are attempting to develop your own host SWD interface/debugger in place of existing solutions, is that right ? It is a relatively ambitious objective for which it will be difficult for us to provide support. The SWD protocol is defined by ARM and you already pointed the right document required to implement it. We don't have timings or waveforms to share, and moreover I'm not convinced it might help. If you really need it, you may probe the signals from a Nucleo board for instance. I may also suggest to look at the CMSIS-DAP firmware which could be an easy way to have a first functional implementation of the protocol if yours does not work.

Some clues which may help in the early phase of SWD protocol implementation:
- do it with the target under reset, to ensure that the required pins are dedicated to JTAG/SWD no matter the application programmed on the target
- take care of JTAG-to-SWD and SWD-to-JTAG sequences which switch the DP state after power up (DP in JTAG mode after power up)
- the first command to do after the JTAG-to-SWD sequence is a Read DP_IDCODE and the first answer from the target is the ACK of the opcode, to firstly check with an oscilloscope because your read function is perhaps initially not aligned with the turnaround period. This first ACK will mean that the DP correctly switched in SWD mode and understood the opcode, it is the very first step to mandatorily reach.

[butterfly]

Hi,

Many thanks to answer with a wide view. My understanding ARM define protocol and it could exist few differences depending implementations ( do we use a front or a level to detect bit datas?). But with an test and try methodology, I should find the right translation.

My board is based on V5.1 architecture, and didn't seem to me this level uses a software protocol to switch to DP, it started with DP, connections enabling the selecting mode. I'll check. My protocol uses today 100 clock pulses to reset, and 10 pulses to lie on standby mode. Checked with a scope I didn't get the 3 bits word ack, my own hardware staying at low level.

Thanks for the comments, and I accept your answer as a good answer.

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.