Boot-up problems

[DL5SMB]

Is there a way to debug boot-up problems?

I have a 033 display which bluntly refuses to boot your newest demo file. Also the old demo does not boot up anymore, I can switch between the stock firmware and a FW I compiled with Dmitrys sources. Both work well.

But as soon as I load one of your demos, no boot up is possible anymore. I used the precompiled files, compiled them myself (on linux and windows), flashed via ESP32, via Nano. It makes no difference.

Powercycling does nothing and I could not get any succes with the debugging feature of the the Nano-Flasher (tried all options there) either.

Its more than strange as I used it with your old demo before and evrything was okay. Also strange that booting the stock FW after flasing works every time.....

[atc1441]

Hey.
The only real way to debug such a problem is via the UART TX line, the firmware should output something on it with 115200 Baud. Maybe try to directly connect a Usb to UART converter to it.

Also you could try to read back the content of flash and compare it to the firmware, maybe the upload has gone wrong ?! Which is unlickly as your firmware works but who knows.

[DL5SMB]

I just took you advise with the UART connection.
And BAM! - I guess i learned something :-)

So, it took some time, but after a while I got the following:

booted at 0x1a77<\r><\n> Booting FW ver 0x0000010f00000000<\r><\n> -> FW v1.15.0.0<\r><\n> MAC 02:C0:0A:B9:3B:1F:00:00<\r><\n> temp: 23<\r><\n> eeprom has 59 image slots<\r><\n> update: nonexistent<\r><\n> checkin #72 fails<\r><\n> sleep: 791015<\r><\0>

So it noticed its obviously booting, but it just did not clear the screen. The "MAC screen" of the stock firmware persists, so it was just not perceptible something was happening.

And then, after watching the failed checkins, a suspicion grew: Flashing the new FW clearly changed the station the tag was associated to.

I have two stations, an nrf52840 with Dmitrys firmware and and an CC2531 which I use with Daniel Kucera's epaper-station.

So flashing the FW seems to have changed the assocation from the 52840 to the CC2531 (which was not in use at the time I did this ). So I turned the other station on and yes, it was connecting to the CC2531, not the nrf52840 it was associated right before flashing. Strange thing.

I used the tag some days earlier with the CC2531, but switched then to the 52840 as the epaper-station does not create red/yellow colour graphics. Hell, the tag even showed a red image before I flashed the new FW.

So this leads to the question, where is the information regarding the associated station stored?

Within the Firmware and/or within the Infoblock?
I could not find anything in the Infoblock, assuming the first line is only calibration information.

So if this is true, the station information must be stored in FW itself.
But then I don't understand that it does not get erased when a new FW is flashed?

Is there a way to dissassociate a tag from a station via flashing?
Should be, since re-assocating works by flashing. I think assocating a completley new station should not work, due to encryption. Ouch, I am getting a headache, thinking about all this :-)

[atc1441]

Thanks for the long answer.

Mine will be kind of short.

The association data is stored in the external flash, why your display did connect to the other station is strange for me as well, i did add in my firmware that after 2 missed connections it will unacosiate from any station to be "free" again.

Now that i think of it, the nRF station is only associating very close so maybe it was just not receiving anything, the cc station is also happy far away, you can test this by turning on nRF station and of the CC station, reseting the display a few times to simulate missed connections and then putting it very close to the nRF.

Hope that helps

[DL5SMB]

Hi, thanks for the reply and your input.

Sorry for the long texts. Usually writing a problem down helps me processing and getting ideas. So sometimes I step on the solution of a problem during asking :-D

Okay, then I will play around a bit and see if I can recreate the circumstances.

Just for understanding, if I understood corrrectly:

In Dmitry's original protocol description the station defines after how many failed check-ins a tag blanks and after how many it disassociates. These values are sent to the tags and saved during association. right?

And the improvement in your branch is, that the firmware overrides the values the station sent with the order to disassociate after two lost checkins. Is this correct?

[atc1441]

The improvement still uses the values from the Station, but you can define them on that side as well.

Only hard coded values are different. Like retry counter for Association and similar