After uploading code, it stops working??

[MedadRufus]

uploading flight_code_17_Dec_2021.hex occasionally does not allow it to startup. Steps to reproduce:

1. wipe eeprom through stm32cube programmer
2. upload this code.

Symptoms: you will be able to connect and program it again. Serial output looks like this:

[MedadRufus]

On the other tracker with suspected faulty crystal, the code runs around half speed.

[MedadRufus]

The code running was commit ada63af147ea638ade7f7e273604b91ddbc73322

[MedadRufus]

Issue still present when low power disabled.

[MedadRufus]

Symptoms:

1. even after programming, its possible to program the device. This should not happen when it goes into low power mode.
2. After programming, it will not blink or run any code.

Possible sources of error:

1. Somehow, boot0 is pulled up. I have accidentally discovered that if boot0 is pulled up, it will only run the code for eeprom wiper, but not the flight code.
2. The LSE crystal is not working.

[MedadRufus]

its not boot0 is pulled up. Could be LSE crystal failure. But its a mystery to me why the first program runs, but not the second.

[MedadRufus]

Switching to running only on LSI does not fix it.

[MedadRufus]

Could somehow, boot0 be pulled up by a soldering error??

[MedadRufus]

Consider sending Steve a few firmware images, and let him load and check if they run. Try to divide and conquer.

[MedadRufus]

All the info I have from Steve:

• Running run_only_once.hex works. Blinks and eventually goes solid. This code only wipes the EEPROM and goes into an infinite loop doing nothing. Code size is smaller(67748 bytes)

  [build]    text    data     bss     dec     hex filename
  [build]   63700     720    3328   67748   108a4 LoRaMac-periodic-uplink-lpp

• Running 7aa5b8076700ccb985f5e40d0532231053774886 does not work. No LED comes on. This is code that use the LSI oscillator instead of LSE oscillator and does not go into deep sleep

  [build]    text    data     bss     dec     hex filename
  [build]  168496    1328    8860  178684   2b9fc LoRaMac-periodic-uplink-lpp

• Running ada63af147ea638ade7f7e273604b91ddbc73322 does not work. No LED comes on. This is the code that runs on the original oscillator and is meant to go into deep sleep. Steve is able to reprogram it multiple times after programming it, suggesting that early in execution, even before running deep sleep, it fails.

  [build]    text    data     bss     dec     hex filename
  [build]  168504    1328    8860  178692   2ba04 LoRaMac-periodic-uplink-lpp

[MedadRufus]

Could somehow, the MCU on Steve's tracker have a smaller flash space due to different variant of processor? I have the STM32L082CZ variant in testing. But I think the processor on Steve's tracker was from another batch of ABZ modules, from Richard.

[MedadRufus]

The ABZ module variants are:

1. CMWX1ZZABZ-091
2. CMWX1ZZABZ-093
3. CMWX1ZZABZ-078

Note that Steve's tracker could handle the old picotracker lora code(compiled with keil). I don't know that code size. Maybe check what size that was.

[MedadRufus]

Compiling the old picotracker code(commit 90b6139331d7e5baef461a63c06570be112ad7e4), I see that it compiles to 99708 bytes:

.\mlm32l07x01\Picotracker_lora.axf: error: L6050U: The code size of this image (99708 bytes) exceeds the maximum allowed for this version of the linker.

So maybe somehow, the MCU on Steve's tracker is a 128kb flash version, not 192 kb flash. 66kb and 99kb sized images load and run OK, but not 178 kb images.

[MedadRufus]

Something to think about: could somehow, a soldering error be causing the tracker to use only the first flash bank? I know setting the boot0 and boot1 pins will make a difference.