I am having a bit of trouble programming my firmware into the P1 module. I am using sparkfun photon RedBoard for the test case. The programmer is st-link v2 mini from adafruit, https://www.adafruit.com/product/2548 .
I was able to connect to the p1 module and program the module with the STM32 ST-LINK Utility. But after I program my user firmware on to 0x080A0000 with Program and Verify on STM32 ST-LINK Utility. The redboard led does not light up and I can’t set the mode or reset the board. I am assuming I can change the start address on Program and Verify to point to the user firmware address 0x080A0000 and hit start to program the user firmware. Please correct me if I am wrong. Are there anyway to correct this problem? Thank you
You’ll probably need to put the board into DFU mode (blinking yellow) by holding down RESET and MODE, releasing RESET and continuing to hold down MODE while it blinks magenta until it blinks yellow, then release.
The reason is that normal operating mode will interfere with connecting by SWD.
Other than that, your process seems normal and ought to work.
@rickkas7, I did put the Redboard in DFU mode before I flash the user firmware at address 0x080A0000 with ST-Link Utility. When I did a comparison of the device memory(p1) vs user firmware on start address 0x080A0000 - No difference found. This tell me the user firmware is downloaded. But the odd thing is that I don’t have to put the Redboard in DFU mode when I hook up the st-link v2 mini to the USB which I do have to when I first started.
Oh, wait, so you can’t reset the board or change the mode at all now? If you boot it does it just boot into a dim D7 LED with no other lights and no ability to change the mode now? If so, then you need to reprogram the boot loader.
Yes, when I boot with the usb connection I have a dim d7 LED and power led on the Redboard, no RGB light and can’t change mode at all or reset. Hmm… how can downloading user firmware broke the boot loader? I will see if I can re flash the boot loader and user firmware and see what happen.
The boot loader shouldn’t have been erased, unless you flashed something to 0x8000000 or erased sector 0. In any case, at least it’s easy to fix since you have a SWD/JTAG programmer.
And also, that’s why you don’t need to enter DFU mode for SWD to connect now. Without the boot loader basically nothing is running, so there’s nothing to interfere with the SWD connect. It’s not that DFU is required to connect to SWD, it’s just the absence of normal running code that’s required, and not having a boot loader qualifies as not normal running code.
@rickkas7, I think I know what happen. In the ST-Link Utility Program and Verify pop up, once you change the file path for the bin, the start address goes back to the boot loader address 0x08000000, even I change it at the beginning. So when I hit start it loads into the boot loader. This will be a pain in the assembly line.
I wonder how Particle flashes the firmware in the assembly line. Is OpenOCD the way to go on assembly line?
Just found out in the ST-Link installation directory, there is ST-Link cli command and you can used to re flash your firmware. Just want to put it out there.
@rickkas7, I have encounter another problem, after flashing the boot loader and user firmware with St-Link Utility. I try to setup the device and claim it today but it stuck at Verify device ownership on the App. When I rest the RedBoard with the reset button. The RGB flashes Cyan and red. After reading the forum, it look like I need to run
particle keys doctor “DevID”
Do I have to do this every time I update the boot loader or user firmware? Thanks.
Not if you only replaced the boot loader, system firmware, or user firmware.
But if you accidentally overwrote sectors 1 and 2, which you may have done when you accidentally wrote firmware to 0x8000000, then you’ll overwrite the server and device keys and you’d need to do a:
particle keys doctor YOUR_DEVICE_ID
particle keys server
The keys server command will reset the public key for the production server, which you’ll probably also need to do.
@rickkas7, when I reinstall the ParticleCLISetup.exe, just to make sure I have the latest update, the log said openssl is installed but when I run
particle keys doctor My_DEVICE_ID
Error creating keys… Error: Command failed: openssl genrsa -out My_DE_rsa_new.pem 1024
’openssl’ is not recognized as an internal or external command,
operable program or batch file.
Is the openssl part of the build or I am doing something wrong? Thanks
OpenSSL is part of the CLI install now, but wasn’t originally. Since I think the installer changes the path you probably will need to at least log out of Windows and log back in again if not actually restart in order to get the change to take effect.
@rickkas7, I restarted my laptop a few times and still the path did not update. To make it work, I have to go into Windows 10 path variable to update the openssl path and the dfu-util path. After running
particle keys doctor YOUR_DEVICE_ID
particle keys server
The Redboard rest to safe mode. So I use the ST-Link Utility to flash the boat loader, system (p1) and user firmware (tinker) then rest the board. Still flash in the safe mode. But it let me claim the device. Its not until I program OTA with Particle Dev that will get out of safe mode.
Is there any reason why I can’t get the p1 module out of safe mode by using the ST-Link Utility? According to what I red, the module enter safe mode when no application code or not valid.
@rickkas7, Thanks for reminding me, the bin need to be in the correct platform. I got the tinker binary from https://github.com/spark/firmware/releases . LOL, a closer look at the tinker bin, it is for the core. Now I can make sense of why the module flash in safe mode. I will have to make a note on this for future. Thank You.