Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Program does not start when uploaded via bootloader
Goto page 1, 2, 3  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Unsupported versions
View previous topic :: View next topic  
Author Message
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Tue May 22, 2018 2:22 pm    Post subject: Program does not start when uploaded via bootloader Reply with quote

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 )
Back to top
View user's profile
EDC

Bascom Expert



Joined: 26 Mar 2014
Posts: 692

poland.gif
PostPosted: Tue May 22, 2018 4:06 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Visit poster's website
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Tue May 22, 2018 6:03 pm    Post subject: Reply with quote

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
Back to top
View user's profile
i.dobson

Bascom Expert



Joined: 05 Jan 2006
Posts: 1534
Location: Basel, Switzerland

switzerland.gif
PostPosted: Wed May 23, 2018 7:32 am    Post subject: Reply with quote

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

_________________
Home of AVRTimer, the Bascom timer value calculator.
http://www.planet-ian.com

Walking on water and writing software to specification is easy if they're frozen.
Back to top
View user's profile Visit poster's website
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Wed May 23, 2018 2:45 pm    Post subject: Reply with quote

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
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Wed May 23, 2018 5:43 pm    Post subject: Reply with quote

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
Back to top
View user's profile
i.dobson

Bascom Expert



Joined: 05 Jan 2006
Posts: 1534
Location: Basel, Switzerland

switzerland.gif
PostPosted: Wed May 23, 2018 6:15 pm    Post subject: Reply with quote

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

_________________
Home of AVRTimer, the Bascom timer value calculator.
http://www.planet-ian.com

Walking on water and writing software to specification is easy if they're frozen.
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1813

blank.gif
PostPosted: Wed May 23, 2018 6:19 pm    Post subject: Reply with quote

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.
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Wed May 23, 2018 7:40 pm    Post subject: Reply with quote

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
Back to top
View user's profile
i.dobson

Bascom Expert



Joined: 05 Jan 2006
Posts: 1534
Location: Basel, Switzerland

switzerland.gif
PostPosted: Wed May 23, 2018 9:33 pm    Post subject: Reply with quote

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

_________________
Home of AVRTimer, the Bascom timer value calculator.
http://www.planet-ian.com

Walking on water and writing software to specification is easy if they're frozen.
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1813

blank.gif
PostPosted: Wed May 23, 2018 9:58 pm    Post subject: Reply with quote

autoguider wrote:
As far as I know changing fusebits is only possible when using the ISP interface.
That is correct.
Quote:
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)
If BOOTRST is set to 1 (0=active, 1=inactive), Extended=F9 the boot vector is &h0000, thus the bootloader is not called.
Well, if the chip is empty=everything &hFF, the controller swallows it as 'invalid opcode' and runs over it till it reaches &h1C00, the bootloader's address. In this case the bootlader is executed even the boot-vector points to &h0000.
Quote:
To my opinion the bootloader does not work anymore.
That is a possibility which I've suggested and which I've showed how to test. From your reply I'm not sure, if you tried in exact the suggested order.
Quote:
The parameters for the MCS bootloader are set to bootsize =1924 and reset = NONE.
Is 1924 a typo or real?
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Wed May 23, 2018 11:44 pm    Post subject: Reply with quote

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
Back to top
View user's profile
i.dobson

Bascom Expert



Joined: 05 Jan 2006
Posts: 1534
Location: Basel, Switzerland

switzerland.gif
PostPosted: Thu May 24, 2018 8:24 am    Post subject: Reply with quote

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

_________________
Home of AVRTimer, the Bascom timer value calculator.
http://www.planet-ian.com

Walking on water and writing software to specification is easy if they're frozen.


Last edited by i.dobson on Thu May 24, 2018 11:33 am; edited 1 time in total
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1813

blank.gif
PostPosted: Thu May 24, 2018 8:24 am    Post subject: Reply with quote

autoguider wrote:
I understood the testing procedure in the following way.
Load the compiled bootloader via ISP.
Load the application program via ISP.

You understood it wrong.
Loading the application program via ISP as second step overwrites/deletes the bootloader.
Anytime the flash is written via ISP, the entire flash is written, which includes the bootloader-section.

1.) flash bootloader via ISP.
2.) set BOOTRST to 0 via ISP, extended fuse F8, sets boot-vector to &h1C00
3.) start bootloader and flash application via serial/bootloader
4.) set BOOTRST to 1 via ISP, extended fuse F9, boot-vector is application boot at &h0000 then.
5.) reset controller.

In case the bootloader's write-to-flash part was working ok, the application is properly flashed after step (3).
If switching back the boot-vector to application start and resetting the controller (step (5)) leads to proper working of the application, then conclusion is that the bootloader is able to flash, but not able to properly boot to application section after flashing.
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 62
Location: Aachen

germany.gif
PostPosted: Fri May 25, 2018 5:45 pm    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Unsupported versions All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
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