Win and Linux: issues during loading and running .hex files for AVR microcontrollers

Dear developer,


I'm unable to load and run .hex files for AVR microcontrollers, either in Windows 10 and Linux Mint 20 (appimage). Sometimes the program crashes during the .hex file loading; in others, it crashes after some seconds of simulation.

In Linux, I was able to load SimulIDE using the terminal, and the following error has prompted:

avr_gdb_init listening on port 1212
corrupted double-linked list
Aborted (core dumped)

The issue was found in 0.3.12 and 0.4.13 versions.


I appreciate your comments.

Best regards,

Douglas Cavalcante.

Hi.

I'm unable to load and run .hex files for AVR microcontrollers, either in Windows 10 and Linux Mint 20 (appimage). Sometimes the program crashes during the .hex file loading; in others, it crashes after some seconds of simulation.

Where did you get that hex file?
Can you provide the hex file that causes this problem?

In Linux, I was able to load SimulIDE using the terminal, and the following error has prompted:

avr_gdb_init listening on port 1212
corrupted double-linked list
Aborted (core dumped)

I don't understand exactly what you are doing.
You open simulide from a terminal, then you load a .simu file with an AVR?

Hi, sorry for my late.


The hex file was generated by MikroC compiler. It's a simple example of led blinking. The file is attached. But, the same problem has occurred with other files.

About the second question, yes. As the problem has occurred using by the normal way, I tried to open the SimulIDE using the terminal to see if there was some message. I don't try to load a .simu file, only place an ATMEGA 328, a LED, and tried to run the hex file.


Thanks in advance,

Douglas.

The hex file was generated by MikroC compiler. It's a simple example of led blinking. The file is attached. But, the same problem has occurred with other files.

Ok, this is an issue with hex files generated by MikroC compiler.
It is already solved and will be available for next version.

I tested your Led_Curtain.hex in simulide development version and it is working ok:


There is not easy workaround for this issue while next version is released.
But i will explain the problem just in case it somehow helps:

Problem with these hex files is that they are not ordered by memory address.
Taking the LedBlinking.hex you provided:

Code:

:100000000C942F000C9400000C9400000C94000041
:100010000C9400000C9400000C9400000C94000060
:100020000C9400000C9400000C9400000C94000050
:100030000C9400000C9400000C9400000C94000040
:100040000C9400000C9400000C9400000C94000030
:040050000C9400000C
:10005E00BFE5BDBFB8E0BEBFBFEFBABBBFEFB7BB1A
:10006E00BFEFB4BBBFEFB1BBB0E0BBBBB0E0B8BB42
:10007E00B0E0B5BBB0E0B2BB29E216E900E80A95E4
:10008E00F1F71A95E1F72A95D1F7BFEFBBBBBFEF9A
:10009E00B8BBBFEFB5BBBFEFB2BB29E216E900E8B4
:1000AE000A95F1F71A95E1F72A95D1F7DDCFFFCF33
:0000BE0042
:0A00540005900D920197E1F7089561
:00000001FF

Second to last line goes to address 0x0054, but is placed after lines with higher addresses:
:0A00540005900D920197E1F7089561

If you move that line to it's corresponding place it should work in simulide 0.4.13 (and older):

Code:

:100000000C942F000C9400000C9400000C94000041
:100010000C9400000C9400000C9400000C94000060
:100020000C9400000C9400000C9400000C94000050
:100030000C9400000C9400000C9400000C94000040
:100040000C9400000C9400000C9400000C94000030
:040050000C9400000C
:0A00540005900D920197E1F7089561
:10005E00BFE5BDBFB8E0BEBFBFEFBABBBFEFB7BB1A
:10006E00BFEFB4BBBFEFB1BBB0E0BBBBB0E0B8BB42
:10007E00B0E0B5BBB0E0B2BB29E216E900E80A95E4
:10008E00F1F71A95E1F72A95D1F7BFEFBBBBBFEF9A
:10009E00B8BBBFEFB5BBBFEFB2BB29E216E900E8B4
:1000AE000A95F1F71A95E1F72A95D1F7DDCFFFCF33
:0000BE0042
:00000001FF

This is not that MikroC compiler hex files are wrong, just that simulide expected lines to be sorted as most compilers do.

Thank you very much for your reply. And congratulations on the simulator. It's a very good initiative.

I understood the workaround. Thank you.

Douglas.