how to upload binary to ART-PI?

[zdima]

Pardon for trivial question, but how I upload compiled binary to ART-PI?
Things are complicate for me since I am working on MacOS and RT-Thread Studio not available there.
I am using command line scons to build binary.
I compiled an example project and I see rtthread.bin and rtthread.elf in the build folder.

Usually I would use openocd or removable folder to copy .utf fle.
But I can't find examples on how to do this with ART-PI (perhaps search in english won't find what i am looking for).
I don't want to loose factory code already on the board's flash (WiFi driver, etc) as it would be another problem for me.

Also, is it possible to upload factory code from the board's flash into a file so I can restore it later if i accidentally corrupt it?

[whj4674672]

https://gitee.com/iysheng/redclock/blob/master/misc/mission_00/m00.md

[StackYuan]

Pardon for trivial question, but how I upload compiled binary to ART-PI? Things are complicate for me since I am working on MacOS and RT-Thread Studio not available there. I am using command line scons to build binary. I compiled an example project and I see rtthread.bin and rtthread.elf in the build folder.

Usually I would use openocd or removable folder to copy .utf fle. But I can't find examples on how to do this with ART-PI (perhaps search in english won't find what i am looking for). I don't want to loose factory code already on the board's flash (WiFi driver, etc) as it would be another problem for me.

Also, is it possible to upload factory code from the board's flash into a file so I can restore it later if i accidentally corrupt it?

Hi zdima:

ART-Pi factory code uses bootloader(internal flash at 0x0800 0000) + application(external norflash located at right-bottom Winbond QSPI flash and addr is 0x9000 0000).

• You can just erase bootloader and do whatever you want, because openocd without external flashloader won't do harm on external flash.
• Most examples are based on external Flash, so you have to modify linkscript and SCB->VTOR address or do something to support external flashloader.
• ART-Pi has been supported on ST's STM32CubeProgrammer, you may follow this doc : https://github.com/RT-Thread-Studio/sdk-bsp-stm32h750-realthread-artpi/blob/master/documents/UM5006-RT-Thread%20ART-Pi%20%E6%95%B0%E6%8D%AEflash%E6%93%A6%E5%86%99%E6%89%8B%E5%86%8C.MD
• Don't worry about factory image, it has been in this project dir: sdk-bsp-stm32h750-realthread-artpi/tools/firmware/Resource_16MB.bin

[zdima]

Thank you for this information. I was able to connect with STM32CubeProgrammer.
I found the STM32 flash at 0x08000000 and factory data (16MB) is at 0x70000000 addresses.
However, I can't read any data from 0x90000000 address. Does it mean the 8MB norflash is defective?

  11:37:48 : UPLOADING ...
  11:37:48 :   Size          : 256 Bytes
  11:37:48 :   Address       : 0x8000000
  11:37:48 : Read progress:
  11:37:48 : Data read successfully
  11:37:48 : Time elapsed during the read operation is: 00:00:00.094
  11:37:53 : UPLOADING ...
  11:37:53 :   Size          : 256 Bytes
  11:37:53 :   Address       : 0x70000000
  11:37:53 : Read progress:
  11:37:53 : Data read successfully
  11:37:53 : Time elapsed during the read operation is: 00:00:00.192
  11:37:56 : UPLOADING ...
  11:37:56 :   Size          : 256 Bytes
  11:37:56 :   Address       : 0x90000000
  11:37:56 : Read progress:
  11:37:57 : Error: Data read failed

[StackYuan]

Thank you for this information. I was able to connect with STM32CubeProgrammer. I found the STM32 flash at 0x08000000 and factory data (16MB) is at 0x70000000 addresses. However, I can't read any data from 0x90000000 address. Does it mean the 8MB norflash is defective?

  11:37:48 : UPLOADING ...
  11:37:48 :   Size          : 256 Bytes
  11:37:48 :   Address       : 0x8000000
  11:37:48 : Read progress:
  11:37:48 : Data read successfully
  11:37:48 : Time elapsed during the read operation is: 00:00:00.094
  11:37:53 : UPLOADING ...
  11:37:53 :   Size          : 256 Bytes
  11:37:53 :   Address       : 0x70000000
  11:37:53 : Read progress:
  11:37:53 : Data read successfully
  11:37:53 : Time elapsed during the read operation is: 00:00:00.192
  11:37:56 : UPLOADING ...
  11:37:56 :   Size          : 256 Bytes
  11:37:56 :   Address       : 0x90000000
  11:37:56 : Read progress:
  11:37:57 : Error: Data read failed

Hi zdima:
There is 0x2000 0000 offset in programmer flashloader side，because in RM0433.pdf, if mcu work on XIP mode, it won't be able to write in QSPI flash.
But in mcu sight, it needs to be ready in XIP mode in bootloader stage, before jump to external QSPI flash(Application).
That's why when flashing / probing / readback needs to be at 0x7000 0000, and mcu needs to Jump to 0x9000 0000.

[zdima]

Thanks @StackYuan!
To summarize my understanding:
The W25Q64JV connected to MCU with QSPI interface and can be accessed in XIP mode at 0x90000000.
The W25Q128JV connected with SPI interface and can be accessed programmatically and it is not mapped to MCU address space.
Am I correct with above statements?

[StackYuan]

Thanks @StackYuan! To summarize my understanding: The W25Q64JV connected to MCU with QSPI interface and can be accessed in XIP mode at 0x90000000. The W25Q128JV connected with SPI interface and can be accessed programmatically and it is not mapped to MCU address space. Am I correct with above statements?

Yes, you are correct :)

[zdima]

i was able to program main flash with boot-loader code, but was having issues to upload application code into download partition.
I was unable to use any ART-Pi_W25Q64.stldr files from this repo with STM32CubeProgrammer v2.12.0, which refuses to load them.
Had to learn and build the external-loader myself for ART-PI. Now, I can build and flash application directly into QSPI flash.

How do I share new ART-Pi_W25Q64.stldr that works with STM32CubeProgrammer v2.12.0?

[StackYuan]

Sounds a lot of hardwork you've paid into, thats awesome!
My PC uses CubeProgrammer v2.9.0, and i'm curious about if you may test your flashloader on newist version?
You may also make a PR to this project, after your testing.
Thanks

[zdima]

Thanks @StackYuan :)
I was using latest STM32CubeIDE to build stldr.
It was complaining about out-dated ST-LINK firmware and wanted to upgrade it and won't continue.
I was hesitant to do so as I know my STMProgrammer and it's CLI are working just fine.
Now, if I update the STMProgrammer, it may require me to upgrade firmware of the ST-LINK too.

Is it safe to update the ST-LINK firmware?

Otherwise, I would prefer to keep current version of STMProgrammer as I know I have the working setup.

[StackYuan]

Thanks @StackYuan :) I was using latest STM32CubeIDE to build stldr. It was complaining about out-dated ST-LINK firmware and wanted to upgrade it and won't continue. I was hesitant to do so as I know my STMProgrammer and it's CLI are working just fine. Now, if I update the STMProgrammer, it may require me to upgrade firmware of the ST-LINK too.

Is it safe to update the ST-LINK firmware?

Otherwise, I would prefer to keep current version of STMProgrammer as I know I have the working setup.

It's safe to update ST-Link frameware.
If somehow accidently happens (eg: bricked), I didn't fail once, by the way. There are probe solder pads at back of the PCB board. You can probe on stm32f103 and reflash it.

Normally, you just upgrade it, and it simply works fine.

[zdima]

@StackYuan
The ST-LINK firmware updated.
I also confirmed I have latest version of STM32CubeProgrammer v2.12.0.

Can you try a new stldr file with your version of programmer?
You can find it here:
https://github.com/zdima/sdk-bsp-stm32h750-realthread-artpi/tree/W25Q64/debug/stldr
I will send PR once you can confirm it works with your version.

Thanks

[StackYuan]

@StackYuan The ST-LINK firmware updated. I also confirmed I have latest version of STM32CubeProgrammer v2.12.0.

Can you try a new stldr file with your version of programmer? You can find it here: https://github.com/zdima/sdk-bsp-stm32h750-realthread-artpi/tree/W25Q64/debug/stldr I will send PR once you can confirm it works with your version.

Thanks

on this pr #249 we've fixed this problem.