Debugging application in bootloader

[Witya]

Hello everyone!

I would like to know if it is possible to debug the application that is loaded to MCU with bootloader.

Because application works perfectly if it is flashed directly to MCU, but when it is loaded through bootloader, does not work as expected...

cheers,
Victor

[Witya]

anybody?

I have to know how it works inside the damned bootloader...

[tonyp]

You don't give much information as to what the exact problem is, or how your bootloader works, or in what way your app fails (e.g., does not run at all, runs and crashes, etc.).  The simplest bootloader should simply check if an app is present (possibly via a CRC check) and run it, or else wait for a firmware upload.  A more involved bootloader may include a complete set of libraries or RTOS, using several MCU resources by itself providing some kind of API to your app.

Obviously, a bootloader, being just another piece of code, can be debugged just the same.  Just consider the bootloader to be your actual application.  You should then be able to trace the code all the way to loading and executing your app.  You may have to load a different map file when you cross from the bootloader to the app (since these two are usually assembled/compiled independently.)

Regarding why your app behaves differently stand-alone and under the bootloader, there are far too many possibilities, which all depend on how your bootloader works.  In general, though, check that:

* App vectors end up where the bootloader expects them (e.g., hardware or software redirection), or your interrupts won't work.

* CRC checks (if used) should allow for relocatable vectors, or else the CRC might fail causing the app to not start.  In case of failure, a bootloader would normally end up in a firmware-upload mode, or waiting for commands (like Upload, Dump Memory, etc.)

* The bootloader does not use any interrupts used by the app (e.g., SCI interrupts).

* The bootloader does not set the protection (you should be able to assemble/compile your bootloader with a conditional that leaves everything unprotected so you can debug)

* The bootloader does not lock one-time writable registers (eg., COP) that your app needs to change.

* If part of the bootloader (e.g., certain ISRs) run in the background at all times, make sure the app does not overwrite bootloader variables.

Many more...

[Witya]

MCU is S08SG32

bootloader AN2295.

project used hc08sprg-s08sh.mcp (TB1RB0 (TxD/RxD))

there is an application written by another developer, that works with this MCU, serializer-deserializer and another chip (cannot say which because of the confidentiality)

so I used aformentioned project for bootloader. I added some code, so link between serializer and deserializer is established.

_______________________________________

bootloader works, loads s19 file (compile output of the application) and launches it (I think... at least jumps to application execution).

But I see no output of the application (that has been developed by another guy)

I would like to be able to debug this application, if it is possible.

P.S. bootloader sees the realocatable vectors and executes JMP ,X (means it jumps to application). since I changed registers in .asm and .prm I had to change it in PVEC0 function (.asm file main)

P.P.S. currently I am trying to find if app overwrites bootloader variables. but after switchig off and on the MCU, I am able to reload any other app (s19 file), if not, it executes the app, because #ACK file is not in the Tx/Rx.

P.P.P.S. I had an idea that bootloader screws data direction Tx to Rx, when application loads from Rx to Tx, have to talk with head developer about it.

any ideas on anything I tried to explain? if anything is not clear, just tell and I will write as understandable as possible.

[Witya]

Checked the app vectors.

they look exactly the same on exactly the same places. from 0x8000 till 0xC016.

interrupts should not be a problem, because they are inserted as _asm CLI (to enable) and _asm SEI (to disable). correct me if I am wrong

I had to comment off some functions from the original app, because, for example, Tx-Rx link is established by the bootloader, so no need to trigger these pins again.

P.S. and still can I debug application within the bootloader state?

[bigmac]

Hello,

There does appear to be some confusion about the subject of interrupt vectors.  These will normally occupy the flash memory address  range 0xFFC0 to 0xFFFF.  When using a bootloader, the vectors are considered under the control of the bootloader, as they require to be setup within the bootloader code, that is placed near the top of the flash memory range.  This block, including the vectors would usually be subject to flash block protection, so cannot be separately erased and re-programmed to suit each application.

Therefore, the application's vectors require to be at a different location, within the flash block occupied by the application code.  This is where vector re-direction enters the picture.  This can be handled by the setup of the MCU itself (refer to the device datasheet), or alternatively by the bootloader code.  In the latter case, the interrupt vectors would need to be at a consistent location known to the bootloader code.  You will need to determine how the specific bootloader handles the vectors.  It also may depend on which interrupts the bootloader itself requires to use during the download process.  Note that the reset vector is not re-directed by the MCU. 

This does mean that code to be directly flashed using USB Multilink, and assuming no bootloader present, (i.e. application vector table starting at 0xFFC0), requires some modification to work in conjunction with a bootloader, unless the bootloader itself were to automatically program the vectors at the alternate location.

I wonder if this is part of the present issue?

Regards,

Mac

[Witya]

hey bigmac,

you are right, when app is flashed, last addresses have sth. (check the attachment 1.bmp)

after bootloader is flashed, there are other stuff (attachment 2.bmp)

the master software on pc, that loads application, copies all the vector table to a new location (attachment 3.bmp)

REL_VECT    EQU     $F0B0    ; (FDC0) newly relocated int. vectors
INT_VECT    EQU      $FFB0    ; (FFC0) start of table of original vectors

original values are in the brackets in the comments

I changed original values, becuause master software was telling me that there is not enough space for the s19 image...

and bootloader finds these relocated vectors because of the function:

PVEC0:          
            LDHX      #(REL_VECT|$00FF)&$FFFE    ; there should be relocated reset vector of the new app.
            LDA          ,X
            PSHA
            AND          1,X
            LDX          1,X
            PULH
            INCA       
            BEQ          slfprg                      ; don't jump if empty vector!                                                   
            JMP           ,X                             ; jump to relocated application!

and apparently jumps to the application. (I conclude it, because to load new application, I have to switch off device and switch it on) so it finds the reset vector.

that is why my BIGGEST QUESTION now (sorry for caps) is wheteher or not I can debug the application that is supposed to be running.

once again any questions are welcome, I will try to explain to you as clear as possible.

I really appreciate your help!

[bigmac]

Hello,

I think that Tony P has already answered your "biggest question".

The code snippet that you posted would redirect only the reset vector, with the new vector (that points to the start of your program) located at 0xF0FE.  In fact this would apply to any low byte value for the RELVECT constant, with the present calculation method.  This seems to imply that your bootloader code would start at address 0xF200 (on a 512 byte boundary), corresponding with a block protection boundary.

However, the particular code snippet shown would not apply to any of the other interrupt vectors, from 0xFFC0-0xFFFD.  For these, there are two possibilities.

Case 1:  Your bootloader does not utilise any interrupts.

You may use automatic vector relocation by setting the FNORED bit in the NVOPT flash register, and enabling flash block write protection.  Assuming that all addresses 0xF200 and above are protected, the vectors will be automatically redirected to the address range 0xF1C0-0xF1FD, where the vector table for the application program would be placed.

Case 2:  Your bootloader makes use of one or more interrupts.

Automatic relocation is not applicable,  Each vector must be redirected using a sub-routines within the bootloader section.  For the device you are using, a total of about twenty sub-routines would be required, since you don't know in advance which of the interrupts an application might use.

Each sub-routine would need to cater for saving and restoring the h-register value, as mentioned by Kef.  Because of this, you might use a JSR ,x instruction, rather than JMP .x.  This would require that the application ISR routines terminate with RTS, rather than RTI, (i.e. would not use the interrupt modifier, if programming the application in C).

ISR_TPM1OVF_:     ; This location pointed to by vector at $FFE8    pshh    ldhx  #$F1E8  ; Relocated vector position    ldhx  ,x      ; Fetch ISR address    jsr   ,x      ; Execute ISR    pulh    rti

While the new vector table could be placed anywhere within the application code area, it is a good idea to stay with the standard location, as above.

I see that your current bootloader code is writing garbage to many of the vector locations (2.png).  If using automatic relocation, each vector should remain unprogrammed (0xFFFF), or maybe point to a default location within the bootloader code.  For coded relocation, each vector must point to a bootloader address.

Regards,

Mac

[Witya]

to bigmac,

let's consider my bootloader like Tony P described

"it  simply checks if an app is present (by checking the redirected reset vector) and run it, or else wait for a firmware upload. "

and it does exaclty like that.

vector for 0xF0FE was copied from 0xFFFE, which is reset vector.

where did you get 0xF200 address value form? application is written to the 0x8000 - 0xF0C0 address area.

8.png shows that there is nothing there, and I don't understant why should there be anything?

Protected address is from 0xFC00 (set by the bootloader)

.prm file of bootloader has these memory placements

SECTIONS /* here all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */

  Z_RAM               =              READ_WRITE      0x0080 TO 0x00AF;
  RAM                   =              READ_WRITE      0x0100 TO 0x017F;
  ROM                  =              READ_ONLY        0xFD80 TO 0xFFAD; //changed from fe00-ffad
  ROM2                =              READ_ONLY       0xFFC0 TO 0xFFF7;   // UNUSED SPACE IN INT. VECTOR TABLE
  NVPROTROM  =              READ_ONLY       0xFFBD TO 0xFFBD;      
  NVOPTROM     =              READ_ONLY       0xFFBF TO 0xFFBF;
  SCI_ROM          =             READ_ONLY       0xFFF8 TO 0xFFF9;   /* 2 bytes in unused vector table */
END

PLACEMENT /* here all predefined and user segments are placed into the SECTIONS defined above. */
SCI_PROT_ROM                                               INTO SCI_ROM;
NVPROT_ROM                                                  INTO NVPROTROM;
NVOPT_ROM                                                     INTO NVOPTROM;
DEFAULT_ROM                                                INTO ROM;
 ROM_2                                                               INTO ROM2;
 _DATA_ZEROPAGE, MY_ZEROPAGE       INTO Z_RAM;

DEFAULT_RAM                                                INTO RAM;
END

VECTOR 0 main
INIT main

apparently these vectors are used only for the bootloader slave (the one on the uC), these are not garbage, but bootloader ROM and RAM.

BTW, the bootloader is written in asm. you can check it here

http://www.freescale.com/webapp/sps/download/license.jsp?colCode=AN2295SW

project "hc08sprg-s08sh.mcp"

and realocation of vectors is done by the master booloader software from the PC (that is used for updating the firmware). I think relocation is done everytime you update firmware (load the app), because each app have their reset vectors.

7.png shows what does the master software.

[bigmac]

Hello,

If the protected flash starts at 0xFC00, and if the programmed value of NVOPT at address 0xFFBF is really 0x82 (i.e. FNORED bit is zero), this indicates that automatic vector relocation will occur.  This means that the vector table for the application, excluding lthe reset vector, must be placed at the address range 0xFBC0 to 0xFBFD (refer to the datasheet).  You do not have a choice.

The vector that points to the start of the application program must be positioned where the bootloader expects it to be.  This might potentially be at 0xFBFE-0xFBFF, but you would need to confirm.

I have assumed that the bootloader itself does no manupulation of the application's vector table addresses contained within the S19 file.

Regards,

Mac

[Witya]

hey mac,

I have no problem with the start vector. application starts, but it doesn't work as it supposed to.

I think that there might be a problem with the I2C interrupts, because output should go via uart using I2C protocol. and I have no idea where to search for these interrupts... 

the application is positioned 0x8000 - 0xF0A0 and start vectors are 0xF0B0 - 0xF0FF.

it finds the vectors and starts the app, but I2C is not working, for some unknown to me reason.

NVPROT_ROM:        SECTION
MY_NVPROT      DC.B    %11111100    ; flash protected (from 0xFC00)

NVOPT_ROM:        SECTION
MY_NVOPT      DC.B    %10000010    ; backdoor enable, redirection enable, (un)secured flash [last 10]

DEFAULT_ROM:    SECTION

this shows that even though the memory is protected 0x82 makes it open to copy all the needed stuff.

[Witya]

and there aremere than 512 bytes there.

519 S-record lines

16465 bytes total

then goes 7.png from post before

[kef]

My bootloader and PC program don't move application vectors for me. This allows to include bootloader S-records as is in application image (HEXFILE bootloader.s19 in *.prw file). This makes debugging as easy as debugging without bootloader, just click run and it all will be compiled, loaded and running. To remove bootloader codes from resulting S-records, I modified bbl file to produce two S19 files, one with bootloader, and another one without bootloader. BBL file for nonbanked application is simple, see attached.

You code for vector redirection doesn't seem right. S08/HC08 doesn't save/restore H register on interrupts, this should be done by your ISR handlers, else applcation will fail at some point. https://community.freescale.com/message/20682#20682

[Witya]

to kef,

my .s19 file has nothing to do with the bootloader... it is application that bootloader has to run.

how my stuff should work

bootloader slave is flashed directly to the uC.

bootloader master software is on the PC, connected to the board that has mux-demux link to the uC. Serial connector (COM3 emulator for usb connected to the board) is used to load application.s19 (firmware) to the uC.

so no bootloader related stuff in the application.s19.

when I am debugging even bootloader's code (which is in asm), ILOP (illegal opperation) maked debugging imopossible. codewarrior says "Error: Unable to go into background mode." and had to do pin trigger thingie, kinda bruteforce

vector redirectioron is implemented by bootloader master software. which is developed by freescale guys for aw2295.