Using SWD protocoll BitBang to read/write STM32F0 flash

[valentin]

Posted on September 07, 2016 at 01:55

Hi there,

I'd like to build an automated pcb flash & test box. The finished pcb will be inserted into the device and then the device detects the presence of a new board, powers it up, flashes the firmware and tests functionality of the new pcb. After all is finished, either a green or red led light up. Now I am wondering how I could get an STM32 to flash another one via the SWD link? I would probably use a high-density type and store the firmware in its flash so that the unit is completely independent. Any ideas? The boot0 pin is fixed to ground on the pcb. But it must be possible top mimick what the PCB does when uploading a firmware using ST-Link? Thanks!

[valentin]

Posted on September 17, 2016 at 09:25

Update:

I'm now at the point where the complete init sequence is working. I have followed these steps: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16html

Power-up handshake:

- write 0x50000000 to the DP.CTRL/STAT register

- poll the DP.CTRL/STAT resgister for 0xf0000000 Activate the correct AP:

- write 0x0 to the DP.SELECT register to activate the AP at position 0 on the DAP bus

Set the AP access size and address mode: - write a suitable setting such as 0x22000012 to the AP.CSW register Set the initial AHB address to access:

- write the desired 32-bit address to the AP.TAR register  including the SWD switchover from JTAG: To use the SWD protocol, the above procedure should be preceded by two initial steps: - issue the benign TMS sequence which switches the DP from JTAG to SWD mode - read the DP.IDCODE

Result: All operations are acknowledged by ACK_OK. But unfortunately, when I write e.g. 0x08000000 into the Transfer Address Register and read the AHBAP Data Read Write either twice or read the DEBUG PORT READBUFF afterwards I always get 0x00000000 as result. it seems I just can't read or write to any memory at all... My steps (out of memory): 1. Line Reset 2. SWD switchover from JTAG 3. Line Reset 4. Two idle clocks to get into idle state (SWD low) 5. Read IDCODE 6. Read AHBAP IDR (SELECT 0xF0, read DRW, SELECT 0x0) 7. Power up Debug 8. Halt Core and Halt on Warm Reset 9. Reset Core Write 0x08000000 to AP.TAR Read DRW (plus read RDBUFF) -> no result. Write 0x2000000 to TAR Read DRW (plus read RDBUFF) -> still nothing. This seems rather odd. According to all step by step instructions I could find so far, all that is required is to write into TAR and read the flash data directly from DRW... Update2: never mind. AddrInc got me. I was reading the wrong addresses to check against. Seems okay now. Only need to figure out how to erase a flash page. Then it's all done!

[jnfo]

Posted on September 21, 2016 at 05:20

Valentin,

Are you able to share the code when you are done for doing this? This is very interesting and something I've been thinking about doing...

[Gustavo.Laureano]

Posted on February 11, 2017 at 00:28

Hi Valentin!

Thank you for sharing all this information!this spared me dozens of hours reading the reference manual!I am trying to put a microcontroller to read the SWO pin from my target micro, so far I read the reference manual and it showed me the SWO output format (UART at 2mhz baud rate and first byte meaning channel/datasize), using a logic analyzer to sniff the traffic between stlink and a stm32f103 target confirmed it, but the SWO output only outputs data when the debugger is connected to the target, so I need to learn how enable the SWO output thru the SWD protocol, and I got stuck exactly at it as the communication between the STLINK and the target is pretty intense and it grabs a lot of information that (I think) is not needed to just enable the SWO output..So, do you know where I can get the SWD command sequence to just enable SWO?Thank you!

[valentin]

Posted on February 11, 2017 at 20:59

Hey,

no unfortunately, I have never worked with SDO so far and I don't know how to enable it.

If you want I can have a chat to my boss at my company and see whether I can release the code I got together so far. Maybe that would be a good starting point for you?

I cannot promise anything though ... It's not too complicated. Just bit bang what I put together at the first posts. The exact sequences are in the manuals.

[Gustavo.Laureano]

Posted on February 12, 2017 at 05:03

Hi Valentin

Don't bother, I am having some progress in understanding how things are done after I dropped the idea about reading ARM documentation and followed

Waclawek.Jan

 suggestion!

I've put OpenOCD to work with my st-link + target, and now I am studying how OpenOCD execute commands like 'tpiu config' and etc, playing with commands in the OpenOCD terminal, seeing it my logic analyzer, and following what is being done thru the OpenOCD source code

After I understand enough, I will start playing with the magic probe firmware to (maybe) reuse the low level transport functions, as magic probe have a firmware version for STM32F103 micro

Thanks! 

[AVI-crak]

Posted on February 12, 2017 at 10:07

Record a flash of memory is standard operation.

The sequence of operations is described in documentation, all necessary peripheral registers shall be set in unique working state. Installation of registers of the periphery through SWD - isn't difficult operation. (but very tiresome) there is a difference in data access: it is necessary to transfer at first the destination, then function reading/record/size, and after data.The only condition - exclusive use of SWD port. All secondary flows need to be finished and forbidden. Secondary flows it is inquiry of memory, other periphery, registers of the SWD.In data transfers for record and reading - don't forget to pull a circuit of a dog (WWDG). Failure shall transfer the processor to automatic erasing of a firmware - transition to a memory section with in advance written binary program. It is much safer to have the pure processor than the processor with an unknown error.