[Solved] Bootloader to program: how to share a byte

spilz · Joined: 30 Jan 2012 Posts: 220

Hello everyone,

I'm working on USB Bootloader on 18F47J53 and it works well.

But now, I would like to be able to "share" a data from the bootloader to the program :

To go into bootloader I have to press a "reset' button for 10s
in fact when I start to press, the PIC restarts, and the bootloader checks during 10s if it's still pressed.

If yes -> waiting for new program.
if not -> start normal program.

I would like to save how long the button is pressed (if less than 10s) and use it in the program (something like in normal program : if press 3s then do something).

Before with 18F2550, I used internal EEPROM, but 18F47J53 does not have it.

I just need to transfer 1 byte and use it at the beginning of the program.

What is the best way to do it ?

Thanks for your help.

regards

Ttelmah · Joined: 11 Mar 2010 Posts: 19569

Using the EEPROM, was going to use it's lives rather rapidly. Just make a variable 'common'. Choose a RAM location, and #locate a variable at this point. Use a global variable (but do not declare this as 'static'). A global variable, without any initialisation value, will be left unchanged when the main code starts (provided you don't use #zero_ram). You can initialise it in the bootloader, but not in the main code.

spilz · Joined: 30 Jan 2012 Posts: 220

That works great, thanks a lot Smile

Rob1955 · Joined: 25 Feb 2017 Posts: 6

Ttelmah · Joined: 11 Mar 2010 Posts: 19569

You are declaring 'status' as global in the actual application?. (so outside the code itself).

You show it as if the declaration might be inside the code. It needs to be outside, like the declaration in the bootloader. Otherwise it becomes only a local variable.

I'd probably suggest putting it somewhere less in the center of the memory map. So perhaps 0x7FE. Problem is that if the compiler wants to allocate a large array, it wants nice continuous blocks of memory.

Look at the .sym file generated by the bootloader, and by the main code. What does it show in the RAM area here?.

Try testing. Write a known value to the variable in the bootloader. Does it arrive successfully?. If so, then the problem is that restart_cause doesn't contain what you expect!...

Rob1955 · Joined: 25 Feb 2017 Posts: 6

Ttelmah · Joined: 11 Mar 2010 Posts: 19569

OK.

What you are describing has all the symptoms of an array used in the bootloader overflowing.

Remember there is no protection on the size of arrays, or areas used by pointers. If you have an array used to build the data up ready to write to memory, and for some reason more bytes arrive than are expected, then data can be written into areas after the array....

Look carefully at what is declared immediately below the data being corrupted. So if the sym file shows (for instance):

0xF0...0xFF buff
0x100 reason

you would need to look at what is written to 'buff'.

On the stack overflow, that is because the PIC24 and similar chips do have a 'data' stack (which the PIC12/16/18 chips don't have). Things like printf using a float use a _lot_ of stack space. The default stack size was too small for quite a lot of functions on some compiler versions. Again unlike the older PIC's, the stack is variable, and all that is needed is to increase the stack size.

To get a stack overflow on a PIC18, _you_ would have to be doing something that results in the stack becoming unbalanced. For instance, jumping out of a routine, rather than returning from it. The compiler knows how much stack it uses, and tells you this. To make this go wrong, requires deliberate action....