Forum - MCS Electronics


FAQFAQ SearchSearch RegisterRegister Log inLog in

Possible programming bug

Post new topic   Reply to topic Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message

Bascom Member

Joined: 03 Feb 2006
Posts: 52

PostPosted: Tue Nov 05, 2019 12:44 am    Post subject: Possible programming bug Reply with quote

Hi all - and first of all, thanks Mark for releasing the new IDE. Running it alongside patched for now, programming with an Olimex AVR-ISP500 with current firmware/drivers and the STK500 Native Driver - on Win 10 Professional x64.

Have installed and had a quick play with it over the weekend and while almost everything looks good, I seem to have encountered a bug in the programmer. All my current projects are compiling without error - and all bar one of them seems to flash fine. The one that doesn't, the error mode is really odd. It's a big one, relatively, running on an M2560 - the .bin currently just over 100KB. The first time I flashed it with the programmer, it flashed and verifies - but the chip didn't boot up. No communication with the display, not even the status LED flash that's the very first bit of code. Nada.

Having first double-checked the programmer settings and found no problems, figured it would be due to changes in the compiler. Not seeing anything in history.txt that applies, I tried comparing a .bin compiled with to the same code compiled with The only (six bytes) differences between the two binaries were two references to the compilation date - so not enough to cause any execution errors. I then flashed the .bin compiled with with the programmer - and it ran perfectly. I've also examined the M2560def.dat included with and there's no meaningful difference with the older one (I wasn't using a customised one). Nevertheless, I tried copying the old one into the new DAT folder - as well as the root folder, just in case. No difference.

I rebuilt the big M2560 project in a fresh .bas inside Initially I pasted everything in. Compiled and programmed without errors, but still wouldn't run. So I wiped it again and then began pasting in code a little at a time. Hardware definitions, then sub declarations, variable definitions and then the device's initialisation sequence, testing as I went. I figured that at some point I would paste in a bit of code that would cause the hang -and then be able to narrow what the problem was.

Sure enough, it ran perfectly - until I pasted in a code block and, after flashing, found a non-booting micro. Yet, flashing the same .bin using's programmer UI and it ran. So there is apparently something specific about the programmer (and maybe specfic to the STK500 native driver) causing the problem - but also I initially assumed it was something specific to the last code block I'd pasted.

I tried remming out a small section of code I'd just pasted in. Flashed, and it worked. So figuring I'd narrowed it down to something in the remmed block, unremmed it and remmed something else. Flashed, and was surprised to find the micro still ran.

I now seem to have narrowed down what's going on. If the .bin is less than 64k in size, the micro will boot and work properly. As soon as the .bin goes >65700 or so bytes the processor becomes completely non-functional. There is a small delta - when the .bin is between 65536 and 65776 bytes - where the processor will start and execute some of its code but it runs very slowly - an initialisation routine that should be done in a fraction of a second takes well over 15 seconds to partially complete - then hangs up completely. I can demonstrate this in practice by remming out any bit of code to bring the binary down below 64K, what's left will work fine. So it isn't like there's one particular block of code or one or two specific commands that's causing the problem. Remming or unremming two or three completely randomly chosen lines to take the final code just above or below 64K will make the difference. And again, the binary that results in a non-func MCU if flashed with will work just fine if loaded into the programmer's buffer and sent to the chip from there.

The programmer is reading the fusebits correctly - and all are appropriately set. That should be a moot point anyway because, as above, the exact same .bin will program and run correctly on the same micro with the same fuses if flashed with the earlier programmer. I can't hypothesise a reason why the filesize is an issue, but that's what I'm seeing. I suppose in due course I could try putting a stopwatch on the programming sequence to see if it's taking as long as it should. I've already tried reducing the clockspeed to see if that helps - no difference.

Possibly a related issue too - the process of diagnosing the above has been complicated by the fact that the "Read chipcode into buffer" function of the programmer also isn't working as it should - and isn't working properly on either. It runs, and creates a .bin file of the expected 256K in size. However, only 64k of the resultant file is populated. Bytes over 0x10000 are all set 0xFF - even when I try and download the full 100K binary that I know is successfully programmed. If I use the 'compare chipcode with buffer' command - that will find a difference at 0x10000 - so my initial suspicion is that the programmer is only writing the first 64K during the programming sequence, even on a chip with more space.

So, is this a bug in the software, or an incompatibility with the Olimex programmer, or? If anyone else encounters anything similar - or can reproduce the symptoms I've described above, or has some other things for me to examine, I'm all ears (or eyes). Already I've seen - in which Ken is unable to get an MCU to run after programming an old, apparently working .bin with's programmer - which sounds superficially similar. Any thoughts?

(BASCOM-AVR version : )
Back to top
View user's profile


Joined: 09 Apr 2004
Posts: 5205
Location: Holland

PostPosted: Tue Nov 05, 2019 10:23 am    Post subject: Reply with quote

A proper test is very simple.
- make a project
- compile it
- take some text file or other file you have with a big size and copy it to the same name with BIN extension.
- progam the chip
- read back the data into the buffer
- save the buffer
- compare the 2 files.

i just did so with a m1281 and all data is correctly programmer/read.
only the last blocks contain additional FF which is to expected for an empty cell.

I did not bother to test with 2081 but this works as expected in 2082.
A number of programmers use the stk500 protocol.

I used an olimex mk2 programmer which should be similar to the one you use.

i can grab a m2560 too. but i would recommend to update the firmware of the programmer.

One thing : each 64K page boundary crossing requires a page load for extended address. the programmer takes care of that. but.. i have seen programmers that do not actually support this. instead they assume you start on address 0 and that you send all pages. they handle the extended address. but that is not a good method since you can not skip empty blocks that way. it is slow too.

so make sure you test using the olimex and that it has the latest firmware and send me some bin file if possible. i will repeat my test with a m2560.

Back to top
View user's profile Visit poster's website


Joined: 09 Apr 2004
Posts: 5205
Location: Holland

PostPosted: Tue Nov 05, 2019 9:09 pm    Post subject: Reply with quote

i do not have a routing board for stk600 for m2560.
So i used m2561 which is similar.

This time i did some extended tests. I made several different bin files.
With blank blocks, blank segments, etc.
I also wrote/read using Studio.
I did found a write problem ! So i can understand you can have a problem.
Reading is never a problem.

Extended address does not seem to work when you skip a segment.
The 2082 skips empty blocks to speed up things. But when crossing a segment that seems to give a problem.

Once i removed it, it works.
Then i checked all docs/info available again. And i checked atmel log from the programmer.
After some experimenting i found out you can not set the address only for the segment (works for reading though), so now i pass it for each block.
And that seems to fix it. This also works with empty blocks/segments which are skipped.

If this is a problem depends on the code. i suspect it only occurs when having empty blocks (page size is FF) and when crossing a 64K segment.
Thus when fiddling with boot loader codes. normal code should not give a problem since it does not have empty blocks.

I will either make a patch available or roll it into the next update.

Back to top
View user's profile Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum