Program does not start when uploaded via bootloader

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Dear All,
I loaded my application program via the MCS bootloader into ATMEGA168. Successfully
But:
My application program did not start.
After loading the application program via the ISP programmer the application programs started well.
I want to keep the processor in it environment and modify the software via RS232.

My assumption is that there is something wrong with the fusebits or the boot vector.
In the application program I set the fuse bits to

$prog &HFF , &HE7 , &HDF , &HF8
With &HF8 I set the bootsize to 1024 words and Fusebit extended Q to select Boot vector.

For the MCS loader I put the parameters for boot size to 1024, Reset NONE

What may be wrong ? Pls be so kind to advice.
BR
Chris

(BASCOM-AVR version : 2.0.7.9 , Latest : 2.0.8.1 )

EDC · Joined: 26 Mar 2014 Posts: 971

Long time ago I have problem with MCS Bootloader with M328P (simillar to smaller 168P)
Problem was that MCS Bootloader uses two or three LED`s for showing the progress.. It was some of the INT0 pins if I remember fine.
To solve this problem I must comment using those LED`s in the Bootloader or config ports again in my aplication after Boot.

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Thx for advice.
I removed all commands in relation to the LEDs in the bootloader, recompiled and loaded into flash memory via ISP.
Message from uploading of the bootloader see MCSBootL_Message.jpg. Does it matter when the message says that 15872 bytes are written and a bit earlier 15818 bytes are loaded into FLASH buffer ?
Checked again content vs. buffer result o.k.

MCSBootLoad1.jpg shows the setting of the bootloader. ARE THE FUSES SET CORRECTLY: ESP: FUSEBIT EXTENDED Q

It looks that the bootloader code is stored at H3800. In the MCS bootloader I indicated Loaderchip =168 and $Loader =$1c00. (see MCSBootLoad2.jpg)
The used $regfile is m168def.dat. Fits to the chipID.
The parameters for the MCS bootloader are set to bootsize =1924 and reset = NONE.
Then uploaded application program via MCS bootloader. Uploading seems o.k. Downloading the Flash memeory via the ISP Programme showed that th flah meory has a new content. Message from uploading was
Loader returned: 123
Uploading
Finish code:0
Trying to run the application program -> no success.

BR
Chris

i.dobson · Posted: Wed May 23, 2018 7:32 am Post subject:

Hi,

What happens if the download the code through the bootloader, then verify it using the ISP? Do you see a difference in the main application section (I'd expect to see a difference in the bootloader section).

That with H3800/1c00 is OK. The 1c00 is address in Words, the address 3800 is in Bytes.

Regards
Ian Dobson

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

I looked for the diffrences in the Flash memory when loading via ISP and MSC Bootloader. At the end of the application program I found memory cell containing the value 1A instead of FF. 1A was by uploading via the bootloader. On the first view I did not find changes at the bootloader.
Do you have some advice how I can just compare the bootloader section ?

BR
Chris

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Here some update.
I checked the bin files via a hexEditor.
No differences in the bootloader code.
I examined the pure bootloader vs. application program loaded via ISP vs. application program loaded via MCS Bootloader.
There are differences in the application code at the end of the application program. That is the only difference.

It is strange.

BR
Chris

i.dobson · Posted: Wed May 23, 2018 6:15 pm Post subject:

Hi,

The 1a/FF difference might not be a Problem. It could will be that the ISP is only writing the Bytes that should be written, where the bootloader is writing whole pages. At what address does the difference occur? How large is the program that you want to write to the CPU? Are the differences behind the end of your application?

I can't imagine that the bootloader would Change. And if the main application verifies from the first to the last Byte then the crap behind it shouldn't matter.

What happend if you Change the fuses so that they reset vector Points to the Main Application, rather than the bootloader? Does the main application then start correctly?

Regards
Ian Dobson

MWS · Joined: 22 Aug 2009 Posts: 2262

After uploading your program via bootloader, reset the boot vector fuse to 1 (default), this disables the bootloader and excution starts at the &h0000 vector.
If the program works then, the bootloader fails to properly start it after uploading to flash.

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Dear All,
The 1A/FF difference occurs after the application program. The application programm and with 2 bytes containing the value 00. The application program ends at H1215. Then the memory is filled with 1A value startng H1216 to H127F. This seems to be the size of a frame.

After changing the fusebits Extended Q to 1:Select RESET vector(0000) via the ISP the application starts properly.
As far as I know changing fusebits is only possible when using the ISP interface.

Then I tried tom upload the application software via the bootloader. I got the message loader returned 123 ( so it seems that the bootloader is still somehow invoked)
Uploading..
Finish code:0
In the message window it indicated Reset chip. It seems that the programming stucks.
To my opinion the bootloader does not work anymore.
The application runs well.
Changing fusebits Extended Q to 0: Select BOOT vector let the bootloader operate properly. Application gets loaded. But Application does not run even after resetting the Atmel. Re-changing the fusebit Q to 1 -> application run!

I would like to have the Atmel processor in its circuit board and do the adaption of the software via RS232.
Do you have an idea what to change at the bootloader.
For me it is strange as I am not the first one using the bootloader.
Nevertheless I cannot explain why it behaves like this.

Please let me have some good advice.

BR
Chris

i.dobson · Posted: Wed May 23, 2018 9:33 pm Post subject:

Hi Chris,

So the Problem is some where in the pass over from the bootloader to the main application (Bootloader jumping to main application).

Can you let me know exactly which bootloader your using on the AVR and the Version of Bascom you're using. If I get the Chance I'll see if I can see anything tomorrow.

Regards
Ian Dobson

MWS · Joined: 22 Aug 2009 Posts: 2262

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Hi Ian,
my compiler version is 2.0.7.9
The bootloader is the MCS bootloader that came with the Bascom examples.
I adapted the source file to the ATMEGA 168 and the frequency of the quartz.
Some section that were contolling some LED I cpommented out of the source file. (see attachment)

@ MWS 1924 is wrong. It should be 1024 (my fingers were too thick)
I understood the testing procedure in the following way.
Load the compiled bootloader via ISP.
Load the application program via ISP.
Start the ATMEL. Result application runs. No indication of bootloader activity.
Download Flash memory into PC. Store the dump for comparison reason.
Next Step:
Load the compiled bootloader via ISP.
Change Bascom to the MCS bootöloader.
Laod the application via the bootloader.
Start the ATMEL. Result Application does not run,
Changing in Bascom to the ISP Programmer
Download Flash memory into PC. Store the dump for comparison reason.

Change fusebit Extended Q to value 1 by Write FSE. Application runs.
For fusebit extended I can read the value F9. Just to be clear attached a screenshot of the fusebit status .

best regards & many thanks in advance
Chris

i.dobson · Posted: Thu May 24, 2018 8:24 am Post subject:

Hi Chris,

I can see nothing wrong with the bootloader code. Could you try updating to a new version of Bascom. You should be able to have both versions installed.

Regards
Ian Dobson

MWS · Joined: 22 Aug 2009 Posts: 2262

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Dear All,
in the meantime I updated to Bascom 2.0.8.1 and used the "old" MCs bootloader. Results are the same.
Then I took the bootloader for ATmega 328p _JeeNode( was in the samples of versin 2.0.7. Cool

and tweaked it to ATMega168.
I loaded the bootloader via ISP and the application via bootloader successfully.
After a reset the application did not start. when I change the fusebit Q to the vector 0000 then my application runs.
To my understanding after a reset on the Atmel the bootloader program is executed. In case the bootloader does not receive the 123 the program counter should jump to &H000 and starts with the execution of the application. For some reason this does not happen.
Please orrect me if I am wrong.
When selecting Fusebit extended Q to value 0 the program execution starts at &H3800 (1c00) which is the begin of the bootloader. The bootloader is executed and waits for a time period to receive 123 In case the 123 does not arrive in time the program counter will be set to 0000 and the execution of the application program starts.

I also checked that both programs are in the memory.

What is wrong ?

best regards

Chris