Particle can't connect to cloud after I flashed it

Troubleshooting
1

We have a few custom boards with a P1 on each. Those were the prototypes and we did a mistake by not adding the mode button.

However, we did add a JTag connector and I was able to flash them with the default bootloader and firmware. After flashing it, the P1 boots up and goes into listening mode. I am also able to almost set it up with the IPhone app. While the P1 can connect to the internet, it can not connect to the cloud. It flashes light blue and in between there is one flash of red. While registering the app I also got an error on the IPhone app saying, that there was an error registering the device and it may be because I already registered it before.

I am certain that this is not the problem since I was able to set up a device twice before ( I went into safe mode or started the listening mode via code and I was always able to register the device again).

Do I need to flash a new private key and/or contact the Particle staff? Or is there another problem?

The firmware I flash is 0.4.9 and specifically for the P1. I do however erase the chip before programming it since otherwise it doesn’t work.

2

This is an issue usually solved with particle keys doctor
But you can also search the forum for “red burst” or “orange burst” (ignore the hits that referency me telling other people the same ;-))

e.g.
Photon setup flashing cyan with a "quick red burst" (now orange burst) [Solved]

1 Like
3

I honestly didn’t think to search for the word “burst” when searching for an answer :flushed: thanks for your answer. However, going into DFU mode might prove to be difficult since we didn’t include a mode button :S

4

Have you got a USB connector?
Then you could use this feature
https://docs.particle.io/reference/firmware/photon/#begin- (I'd guess it will work on P1 just the same)

1 Like
5

You can set the baudrate to 14400 and the Photon will enter DFU mode. That’s with a serial port opened of course :slight_smile:

Opps the answer is already given above. Haha!

1 Like
6

Thanks for the answers :smile:

Maybe that’s a stupid question, but where does the user code go? I thought I was supposed to flash it to address 0x80A0000, but it doesn’t seem to work, the P1 still goes into listening mode. Since I set semi-automatic mode I am pretty sure the code should run before the first connection attempt.

7

If there’s no credentials, it will automatically enter listening mode. I vaguely remember that behavior changes with threading enabled.

8

I managed to get into dfu-mode and run particle keys doctor. However, I don’t think running “particle keys doctor [device id]” is successful since the I get an error and the device doesn’t restart.

The output I get when running the above command is:

Opening DFU capable USB device...
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash   "
Downloading to address = 0x00000022, size = 610
Download        [                         ]   0%            0 bytesInvalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during download get_status
Error saving key to device... Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during download get_status
Make sure your device is in DFU mode (blinking yellow), and that your computer is online.
Error - Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Error during download get_status

The device is in dfu-mode the whole time, so the particle CLI should be able to find it.
Did anyone have a similar problem?

9

What version dfu-util have you got installed?
What was the exact command you used - especially did you substitute the [device id] part?
Have you got the most recent CLI vesion?

10

The dfu-util version is 0.8

I suspect the error has something to do with the CLI version or the network connection speed. On another computer the command runs without problems. Thanks for the help guys :slight_smile:

11

Thanks for the help. Following your suggestions I got it working.

How I did it:

  1. I put the P1 into DFU mode by opening a Serial connection with puTTY with the Speed set to 14400
  2. I ran “particle keys doctor [device_id]”. The above error didn’t actually matter that much.
  3. Depending on if the above error happened, I called “particle keys load [device.der]” where device.der is the new generated key
  4. I sent the new public key to the server calling “particle keys send [device_id] [device.pub.pem]”
  5. I put the device into DFU mode again and called “particle keys server”

I have no idea if all of the above commands are actually necessary, but it worked for me.

Now I have a slightly bigger problem. I tried to flash the device with the default tinker app. It worked perfectly.

But when I tried to flash our application, the device stopped working. The indicator led on one device is only light up a little, when we tried flashing another one, the indicator led starts blinking white. Worst of all, the ST-link isn’t able to connect to the device again.

We tried flashing the tinker app as well as the application via the cloud API, not the flasher. And we didn’t change a thing inside the code.

I cannot paste this code here since it’s a company secret, but I can assure the code is pretty simple, the only thing, that is a little more complicated is the function, where we set the BOR level:

bool setBrowoutResetLevel() {
    
  const uint8_t desiredBOR = OB_BOR_LEVEL3;
  
  if(FLASH_OB_GetBOR() != desiredBOR) {
    //Serial.println("Writing BOR");

    /* Steps from http://www.st.com/web/en/resource/technical/document/programming_manual/CD00233952.pdf */
    /* See also https://github.com/spark/firmware/blob/aefb3342ed50314e502fc792f673af7a74f536f9/platform/MCU/STM32F2xx/STM32_StdPeriph_Driver/src/stm32f2xx_flash.c#L615 */

    /* To run any operation on this sector, the option lock bit (OPTLOCK) in the Flash option control register (FLASH_OPTCR) must be cleared. */
    FLASH_OB_Unlock();

    /* Modifying user option bytes */
    /* 1. Check that no Flash memory operation is ongoing by checking the BSY bit in the FLASH_SR register */
    FLASH_WaitForLastOperation();
    /* 2. Write the desired option value in the FLASH_OPTCR register */
    FLASH_OB_BORConfig(desiredBOR);

    /* 3. Set the option start bit (OPTSTRT) in the FLASH_OPTCR register */
    FLASH_OB_Launch();

    /* disable the FLASH option control register access (recommended to protect the Option Bytes against possible unwanted operations) */
    FLASH_OB_Lock();

    return true;
    //Serial.println("Done writing BOR");
  } else {
     return false;
    //Serial.println("BOR value already set");
  }
  //Serial.println("");
}

The above function was copied from the forums.

Anyone knows what could be the problem?

12

I guess you actually mean the P1?

But when ST-LINK is unable to connect, you are probably a bit stuck.
Let's ping @BDub and see if he can give you the Pro view and maybe you could let him have a NDA and show him your code in private too.

13

Sorry, I meant the P1, yes :slight_smile:

14

I managed to make a few baby steps. I messed up (bricked?) two devices to the point where I wasn’t able to connect to them via the stm32 link utility.

I managed to bring one device back by using openOCD. If anyone will be having the same problems, try to follow this thread:
https://github.com/spark/firmware/issues/31

There is one difference however. Change the content of your .cfg file:

source [find interface/stlink-v2.cfg]
source [find target/stm32f2x.cfg]
reset_config srst_only srst_nogate

Since the P1 has the STM32F205 120Mhz ARM Cortex M3 inside of it, you have to use “stm32f2x.cfg” and I removed this line:

set WORKAREASIZE 0x5000

Since I didn’t really know what it does (I have to google it as soon as my nervous breakdown is over) and it didn’t really make a difference.

Once you run this command:

openocd -f p1.cfg -c "init;reset init"

and you don’t get any errors, you can run puTTY and connect to openOCD via telnet and port 4444.

To Erase the chip, I had to halt the ship, unlock it and erase all the sectors. After that I was able to connect to the P1 via the stm32 link utility again.

The second device is a little more problematic. When trying to connect via openOCD I get the following errors:

Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure

I would really like to know if this is a software or hardware failure since even while the device was OK, I wasn’t always able to connect via JTag (I had to wiggle it a little, I think the pin quality on our custom board is not the best). I am also worried that this device is beyond repair.

Is it even possible to brick the P1 with user code? After I flashed the firmware I checked the sectors, the important ones were write protected so I doubt I was able to mess up the bootloader or firmware.

Also, is it normal, that the P1 flashes white for some time after I flash the bootloader and firmware? This happened with every device I flashed, sometimes I had to reset and even flash it several times before it went into listening mode.

I learned more about chip developing in the last few days than I am confortable with :confused:

1 Like
15

Again thanks for all the help, I would be lost without you guys :smile:

Turns out, the reason I wasn’t able to connect to the P1 via the JTAG connector was because the P1 went nuts if the battery was not connected (USB connection only). That means it’s an issue with the custom board, although I still have to figure out why only the newly flashed devices malfunction without a battery (and only if they run our custom code).

I would like to know one more thing. There are 12 sectors on the chip.
I only flashed the bootloader and the firmware. That means I only wrote to sectors 0x08000000, 0x08020000 and 0x08060000. The user code is located at 0x080A0000. I imagine the keys need one or two sectors too. When I checked the other sectors on a chip (not flashed before), I noticed they are not empty. So what’s on them and why does the P1 work even without me having to write something on those sectors?