A bug that happens only after flashing, dissapers after reset

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very weird bug has been happening lately. Recently I rewrote an asynchronous message-based RS485 driver to use DMA and whenever I try to send a message from ATxMega, the message is sent but 2 last characters are missing and third last character is corrupted (is received as zero all the time). This however happens only directly after flashing the ATxMega and leaving the bootloader. When I reset the ATxMega additionaly (that is I flash it, let it enter the program, and reset it again meaning it enters a bootloader for one second and then finally jumps to the program) this bug dissapers and I successfully receive full messages correctly. Do you guys have any idea where this bug could come from? After each reset a bootloader is executed, it waits one second for data on RS485 link (and if it receives messages with correct destination address, it rewrites flash memory with received data) and then when last frame is received it performs CRC check of the entire flash memory and enters the program with "jmp 0".

This topic has a solution.
Last Edited: Fri. Jul 10, 2020 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Sounds like something doesn't get initialised correctly - ie on reset it is by default, but the operation of the bootloader is changing something. When the application runs, something is not in the same state as on reset.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

deli.dado wrote:
only directly after flashing the ATxMega and leaving the bootloade
Xemag have a register you can use to reset themselves. Do that. In the entry code check the restart reason. If it was a forced reset enter the app. This ensures the Xmega is "fully" reset on leaving the bootloader.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:

deli.dado wrote:
only directly after flashing the ATxMega and leaving the bootloade
Xemag have a register you can use to reset themselves. Do that. In the entry code check the restart reason. If it was a forced reset enter the app. This ensures the Xmega is "fully" reset on leaving the bootloader.

 

OK, thanks. Will try that with software reset if that's what you mean.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

Sounds like something doesn't get initialised correctly - ie on reset it is by default, but the operation of the bootloader is changing something. When the application runs, something is not in the same state as on reset.

 

It must be some peripheral badly initialized. I tried to zero the SRAM memory before entering the app and it didn't help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

deli.dado wrote:
It must be some peripheral badly initialized. 

I wouldn't assume that.

 

I tried to zero the SRAM

That won't necessarily help if, eg, it's a problem with (or related to) uninitialised auto variables ...

 

You need to instrument your code so that you can see what it's doing.

 

Then compare what happens when it "works", and what happens when it doesn't ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

deli.dado wrote:

It must be some peripheral badly initialized. I tried to zero the SRAM memory before entering the app and it didn't help.

 

Have you used "|=" to initialise your registers?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
uninitialised auto variables
awneil wrote:

deli.dado wrote:
It must be some peripheral badly initialized. 

I wouldn't assume that.

 

I tried to zero the SRAM

That won't necessarily help if, eg, it's a problem with (or related to) uninitialised auto variables ...

 

You need to instrument your code so that you can see what it's doing.

 

Then compare what happens when it "works", and what happens when it doesn't ...

I initialize all the variables in the RS485 driver, so this should no be a problem in the RS485 driver itself, but could possibly be a problem with other parts of the firmware?

 

The instrumentation sounds promising, but I don't have any UART output or any peripheral free to ouput values of variables, and even if I had one, this process may take a lot of time.

 

In the end, I solved this by issuing software reset and entering the program directly after detecting one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

deli.dado wrote:
I solved this by issuing software reset and entering the program directly after detecting one
To be honest, well designed botloaders should be doing this anyway. You want to present the app with an AVR that "looks" like it has only just been powered on (whatever the bootloader may have been up to previously).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

deli.dado wrote:

It must be some peripheral badly initialized. I tried to zero the SRAM memory before entering the app and it didn't help.

 

Have you used "|=" to initialise your registers?

 

Good idea. Actually I use |= only for one register in the RS485 code, but I don't modify this register in the bootloader, so it should be OK, but I am fixing this neverthless. Not sure about other drivers and peripherals, there is lot of code to be checked and also I reset most of the peripherals (by writting zero to their control registers and ones to their status registers) before leaving the bootloader, so that should not be a problem, but I can't say that for sure - will check the code and see.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

deli.dado wrote:
this should no be a problem

Ha ha!

 

laugh laugh laugh laugh 

 

How many people have said that, only to eventually find it was the problem?!

 

How many times have we found bugs and thought, "how did this ever work?"

 

Hence it's really important not to jump to premature conclusions.

 

I don't have any UART output or any peripheral free to ouput values of variables

It is really important as part of your design to think about "how will I test & debug this?

 

See:  https://www.avrfreaks.net/forum/how-do-i-check-life-signs-scope-atmega2560-standalone  for lots of tips

 

 

I solved this by issuing software reset and entering the program directly after detecting one.

Yes; as clawson said, that's the way to do it!

 

Now please mark the solution - see Tip #5 in my signature, below:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...