Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Program does not start when uploaded via bootloader
Goto page Previous  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
i.dobson

Bascom Expert



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

switzerland.gif
PostPosted: Fri May 25, 2018 6:13 pm    Post subject: Reply with quote

Hi,

Correct the bootload Loops 5 times in Testfor123 waiting for a character (or a timeout - $timeout = 400000).

If it gets a character 123 or 124 it jumps to the loader section (Loader:)

If is doesn't see a character 123 or 124 the bootload executes a "goto _reset" which does a jump to the normal application (this jumps to address 0).

So the Problem could be that address 0 isn't the correct address for a mega168 or some how the bootloader has changed something in the CPU state so much that the main application can't start.

Could you try adding Abit of code to the bootloader that toggles a pin in the Testfor123 and Monitor this pin. Something like:-

Code:

Testfor123:
#if Cdebug
    Print "Try "; Bretries
    Print "Wait"
#End If
toggle LED
Bstatus = Waitkey()                                         'wait for the loader to send a Byte
 


Maybe the bootloader is starting the bootloader rather than the main application.


Looking at the data sheet I found this:-
Quote:
ATmega48/V does not have a separate Boot Loader Section. In ATmega88/V and ATmega168/V
the Reset Vector is affected by the BOOTRST fuse, and the Interrupt Vector start address is
affected by the IVSEL bit in MCUCR


Maybe the IVSEL Needs to be reset? before jumping to _reset.



Regards
Ian Dobson

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

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Fri May 25, 2018 8:44 pm    Post subject: Reply with quote

i.dobson wrote:
Maybe the IVSEL Needs to be reset? before jumping to _reset.

What makes you believe IVSEL is altered?
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Fri May 25, 2018 9:01 pm    Post subject: Reply with quote

autoguider wrote:
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.
What is wrong ?

It would be interesting to download the flash by ISP after flashing via bootloader.
You can place this downloaded hexfile here and I'll have a look inside.

My theory is that the bootloader commits suicide after uploading the application, by writing too far and overwriting itself.
The ATM168 has no separate bootloader section, which means this actually can happen.
After this, the application would work ok, but as the boot-vector points to the then non-existing bootloader, application start via bootloader fails, while resetting BOOTRST to default starts the application.

I'd suggest to set Bascom-options -> programmer -> mcs loader -> boot size to higher values, try 2048, or max 4096.
This may stop upload earlier.

Alternatively you can try the following hack, if you use BootLoader.bas:
Code:
'...
  Print Chr(nak);                                           ' firt time send a nack
  Do

    Bstatus = Waitkey()                                     'wait for statuse byte

    If Page > 54 Then Bstatus = 4   ' <--- ugly hack ;D

    Select Case Bstatus
       Case 1:                                              ' start of heading, PC is ready to send
'...
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5921
Location: Holland

blank.gif
PostPosted: Fri May 25, 2018 9:13 pm    Post subject: Reply with quote

- you should post the used loader and a sample app you load using the bootloader
- when i have such problems, i program the bootloader using ISP, then i read and dump the file. After programming using the loader, i again read and dump the flash. now you can compare the files.
- the bootedb.bas sample demonstrates how to protect against boot loader overwrite :

Code:
#if Loaderchip = 88                                         'Mega88
   $loader = $c00                                           'this address you can find in the datasheet
    'the loader address is the same as the boot vector address
   Const Maxwordbit = 5
   Const Maxpages = 96 - 1                                  ' total WORD pages  available for program
   Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
#endif


 If Page < Maxpages Then                         'only if we are not erasing the bootspace
     Page = Page + 1                              'next page
     Spmcrval = 3 : Gosub Do_spm                  ' erase  next page
     Spmcrval = 17 : Gosub Do_spm                 ' re-enable page
Else
     Portd.7 = 0 : Waitms 200
End If


also, make sure your other programmer is not interfering : disconnect the ISP cable.

_________________
Mark
Back to top
View user's profile Visit poster's website
i.dobson

Bascom Expert



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

switzerland.gif
PostPosted: Fri May 25, 2018 9:21 pm    Post subject: Reply with quote

MWS wrote:
i.dobson wrote:
Maybe the IVSEL Needs to be reset? before jumping to _reset.

What makes you believe IVSEL is altered?


Grabing at straws really.

I had a Project where I used Interrupts in the bootloader and had to Play with the IVSEL flag to get the main app to boot from the bootloader.

Regards
Ian Dobson

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

Bascom Member



Joined: 24 Sep 2007
Posts: 82
Location: Aachen

germany.gif
PostPosted: Sat May 26, 2018 1:31 pm    Post subject: Reply with quote

Dear All,
here the sourcecode of the bootloader and the dumps collected via the ISP device.
Please change the extension from txt to hex to use it.
Bootloader@application means that the application is uploaded via the bootloader.

Next I will do some indication via LEDs to get the indication what program is working.
Comparing the files I did not find an indication that the application is written into the bootloader section.
I am in doubt about the internal parameter named _reset. I could not find it so I am not sure on the value.

best regards
Chris
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Sat May 26, 2018 11:07 pm    Post subject: Reply with quote

Bootloader&Application.hex contains bootloader as well as application, nothing seems overwritten.
What's obvious is that bootloader code alters the UART registers and these modifications survive the jump to the reset vector &h0000, a jump to _reset only is not a cold start.

In the hex I see that 5 interrupt vectors are used:
Timer/Counter2 Compare Match A
Timer/Counter1 Compare Match A
Timer/Counter0 Compare Match A
USART Rx Complete
USART, Data Register Empty

The latter two are used for buffered serial in/out.
Buffered serial should be that hardened, that it doesn't matter whether UART contains data, UDR is empty, a.s.o., anyway I would give it a try to disable the UART before calling the reset vector:
Code:
UCSR0B = 0
Goto _reset

Needs to be inserted at any place _reset is called.

An alternative clean start would be to run the watchdogtimer into timeout, as a watchdog reset restores all register defaults.
In the bootloader, before doing anything, a test for WDRF in MCUSR tells whether the bootloader has to be executed or the reset-vector is called.
MCUSR is altered by startup code, but Bascom saves the value in processor-register R0.
To start bootloader or reset, $INITMICRO comes handy, as _init_micro: is executed very early at start.
Modifications to BootLoader.bas, not tested, add:
Code:
$Initmicro
'...
do_reset:
  Start Watchdog
Do : Loop

_init_micro:
  Dim myMCUSR As Byte
    myMCUSR = peek(0)
    If myMCUSR.WDRF = 1 Then Goto _reset
Return

Replace any occurrence of
Code:
Goto _reset

beside the one in _init_micro with:
Code:
Goto do_reset
Back to top
View user's profile
EDC

Bascom Expert



Joined: 26 Mar 2014
Posts: 971

poland.gif
PostPosted: Sun May 27, 2018 7:13 am    Post subject: Reply with quote

I test this attached Bootloader Hex couple minutes ago and it works ofcourse. Try it.
Im using baud 38400 and usart friendly crystal 11059200 so my fusebits are : LOW=FF, HIGH=DF, EXT=F8
In attached code you can change crystal and baud to match your hardware. Intention to attach it is that this is the working code.
Back to top
View user's profile Visit poster's website
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 82
Location: Aachen

germany.gif
PostPosted: Sun May 27, 2018 1:28 pm    Post subject: Reply with quote

Dear All,
after the recent investigations it seems to me that the bootloader itself is working properly.
The application is running too.
Fusebits Extended is on F8.
After a reset first the bootloader is started and then the application program.
I control some LEDs in the main loop of the application. This is the indication that the application sotware is running.

The jumps to the vectors seems to be o.k.
So it comes down on the serial communication or some interrupt handling.
I will try now with the watchdog

Further ideas are of course welcome.

best regards
Chris
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 82
Location: Aachen

germany.gif
PostPosted: Sun May 27, 2018 2:13 pm    Post subject: Reply with quote

Some addition.
I put in the bootloader code

Code:
Ucsr0b = 0
Goto _reset

on every location where I have _reset
No effect on the UARtr capabilities of the application.

BR
Chris
Back to top
View user's profile
autoguider

Bascom Member



Joined: 24 Sep 2007
Posts: 82
Location: Aachen

germany.gif
PostPosted: Sun May 27, 2018 3:03 pm    Post subject: Reply with quote

Next addition and dscovery:

it works when bootloader and application are compiled with the identical values of $baud .
My application runs on 19200 Baud and the bootloader was compiled to operate with 57600 Baud.

In the application Config Com1 is programmed as.
Code:
Config Com1 = Dummy , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0

It seems that this config has no influence on the real settings.

I can live with 19200 baud upload speed as the size of the code is in the range of 4k.
If there are other possibilities to a high speed upload and a low speed Uart speed please let me know.


BR
Chris
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Sun May 27, 2018 8:45 pm    Post subject: Reply with quote

autoguider wrote:
My application runs on 19200 Baud and the bootloader was compiled to operate with 57600 Baud.

Then the issue is clear and my guess was right that it had to do with the UART registers.
I've checked again Bootloader&Application.hex and it is actually the way that UCSR0A is written by the bootloader, but not by the application code, while in the bootloader U2X0 (UART double speed) within UCSR0A gets set.
Application code however - because of different baud rate - does not need to set U2X0, assumes a pristine register and does not even write UCSR0A.
Thus U2X0 is still set in application code and you would be able to access serial via 115200 Baud.
End of the story.

Your application actually was started ok, but it appeared to you as non-functional, you could have checked with blinking an led at startup.
No idea why you did not try some very basics of debugging.
Use either my previous advice to clear UCSR0A before _reset (instead of UCSR0B) or use $INITMICRO in your application code and clear UCSR0A there, both will solve the issue.

Btw., using the watchdog reset would have worked then.
Back to top
View user's profile
EDC

Bascom Expert



Joined: 26 Mar 2014
Posts: 971

poland.gif
PostPosted: Mon May 28, 2018 1:43 am    Post subject: Reply with quote

Similar issue was discussed HERE LINK

SO you can even try this code:
Code:
$regfile = "m168pdef.dat"
$crystal = 16000000
$hwstack = 32
$swstack = 16
$framesize = 32
$baud = 19200

Dim Reg As Byte

If Ucsr0a.u2x0 = 1 Then
 Reset Ucsr0a.u2x0     'clear bit so baud will be correct for display this message
  Reg = 1
End If

Do
 If Reg = 1 Then Print "U2X was 1" Else Print "U2X was 0"
  Wait 3
Loop
Back to top
View user's profile Visit poster's website
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 2262

blank.gif
PostPosted: Mon May 28, 2018 9:24 pm    Post subject: Reply with quote

EDC wrote:
Similar issue was discussed

If you had personal experience, why did you not give the right answer in front, but waited till others had to find out?
Back to top
View user's profile
EDC

Bascom Expert



Joined: 26 Mar 2014
Posts: 971

poland.gif
PostPosted: Tue May 29, 2018 11:05 am    Post subject: Reply with quote

@MWS Only when you mention about U2X I remembered that/my case and link them. I dont sorry because I simply forget about it like human can Very Happy
When I post something Im always trying to help.
Back to top
View user's profile Visit poster's website
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 Previous  1, 2, 3  Next
Page 2 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