Undefined constants

1
2
Page 1 of 2

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Undefined constants

· Posted: 19.02.2014 - 14:21 · #1

Hi Rolf.

There are times, particularly when bootloaders are used, when you need to access a part of flash that has not been generated by the current application. As a specific example, we may need to access a constant, e.g. bootloader version, from the main application, to see whether a bootloader needs to be updated.

There are various ways which this can be done, but they seem quite ugly to me. I am wondering whether an extension to AVRCo Pascal could simplify this. I am thinking something like

const
BootloaderVer [@$xxxx] : Word; external;

or something similar, to allow access to a constant that we are not defining. So as far as the compiler is concerned it is treated just like a constant in flash (say like a string constant) but the memory is not overwritten by the hex generated by the compiler.

Would this be difficult?

Administrator

Gender:
Location: Germany
Age: 25
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Undefined constants

· Posted: 19.02.2014 - 18:07 · #2

Hello Merlin,
no problem. Of course a non-physical constant can't be passed from Boot to Main.
We solve a similar problem in two ways (ISP3):
1. having a variable(s) defined in both parts. The boot places some info into this
and the main can read this. Implementation in both parts:

Code

define   IDATA1   = $5FC0;  // iData1 starts here
...
{$IDATA1}
var
{$NOINIT}
  DeviceRecW             : word;
{$NOINIT}
  DeviceRecB             : tDeviceRec;

{$IDATA}          // switch back to standard var area
var
...

2. Using BootTraps. The Boot part provides a function (Trap) which can be called
from the main. This function then can return the necessary infos.
See the example in the Demo directory.
Is this ugly? :aerger:

rolf

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Re: Undefined constants

· Posted: 19.02.2014 - 23:57 · #3

Hi Rolf

I think you maybe miss the point slightly. It is not variables but constants, and the fact that a constant must have a value.

Boot traps might be a possibility - I would have to look into them, but I guess that they assume that a boot section is there, when in fact it might not yet be loaded into flash (in which case it would be $FFFF. That is kind of the point. I know where the constant is, but I don't know what it is. Of course, I could use assembler, or various tricks with pointers, but these solutions are what I would regard as ugly.

Administrator

Gender:
Location: Germany
Age: 25
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Undefined constants

· Posted: 20.02.2014 - 18:21 · #4

Quote by Merlin

There are times, particularly when bootloaders are used, when you need to access a part of flash that has not been generated by the current application. As a specific example, we may need to access a constant, e.g. bootloader version, from the main application, to see whether a bootloader needs to be updated.

Without an existing (programmed) bootloader where can an application read the non-existing bootloader version?
The bootloader is the "hen" and the main is the "egg".
With my first example the bootloader places its serial number and/or version number into these iData1 vars. If the main runs it can read these values out of iData1.
This is the way our programmers are working. At first we program the bootloader with the JTAG or PDI interface. Then after the first startup the bootloader looks for a valid main. If not present the bootloader requests a new main for download.
The main reads some infos out of iData1 and uses them in the expected way.
Btw.
The bootloader should always be restricted to very very simple tasks, checking for a valid main and do a main download, if necessary. If this construction is well done, the bootloader never must be changed. And please note that a bootloader can only be self-programmed if this code exists in the boot area. A main can never program an empty boot area.

rolf

mc-electronic

Benutzer

Gender: n/a
Location: Sauerland NRW
Posts: 372
Registered: 03 / 2008

Subject:

Re: Undefined constants

· Posted: 21.02.2014 - 09:47 · #5

Hello Rolf,

You wrote: [quote]And please note that a bootloader can only be self-programmed if this code exists in the boot area. A main can never program an empty boot area.[/quote]

I am not sure, if I got the meaning of the quote above all right, but a main can program the boot area. I use it often to flash the boot area only from the main to install a boot loader. The trick is to define a bigger boot area then required and put the Flash write procedures of the main at the very end of the main program into the boot area just before the boot loader. It is "ugly", but effective. This way you can update the bootloader from the main and you can update the main from the bootloader..

But coming back to Merlin's problem: the bootloader is only an example, the "problem" is the following: if we want to read data from the flash, we use some construction like the following:

Var
wPtr : Pointer To Word;
CPULoaderVersion[$3FFFA] : Word;
lWo : Word;
.....
wPtr := @CPULoaderVersion;
lWo := FlashPtr(wPtr)^;

This way, lWo contains the value, that is written into flash address $3FFA/B. What Merlin wants, is that the compiler allows a construction like

Var
CPULoaderVersion[$3FFFA] : Word; Imported;
lWo : Word;
...
lWo := CPULoaderVersion;

Regards, Michael

PS: Verflixt, bei mir gehen im Forum nie die ganzen Quote / Code / etc. Sachen im Editor. Sieht immer doof aus..

Merlin

Administrator

Gender:
Age: 25
Posts: 1415
Registered: 03 / 2005

Subject:

Re: Undefined constants

· Posted: 21.02.2014 - 10:32 · #6

@Michael

except it wold be a const, not a var, like this

const
CPULoaderVersion[$3FFFA] : word; Imported;

@Rolf

Just to play Devil's Advocate here, you say that if a bootloader is well written it should never need to be updated. I disagree. If it can be done, there may be sound commercial reasons for updating a bootloader, nothing to do with how well the bootloader is written. :angel12:

Consider this. You have a device with serial comms and an SD card. You decide that serial comms is the way to update your program. But then your customers who are maintenance engineers complain that they have to disconnect the serial port from their customer's equipment to apply an update. Why can't it be on the SD Card so that they can prepare it off site and just swap it when they come on site? So you make the commercial decision to load from the SD card, recalling all your devices in the field to reflash the bootloader. Then all your other customers complain that they are not engineers and now have to open up equipment and the new method is much harder than the old one (while, of course the engineers are very happy). So finally you decide to let the client decide which bootloader to install on setup. But then, of course, your main program needs to know that there is no bootloader installed yet.

Artificial I know, but just to illustrate that there is more to it than just good programming.

BTW. I looked at boot traps, and they would do the job provided that the bootloader can be guaranteed to be present. My suggestion would, of course, be simpler for the programmer and take less code space...

Harald_K

Subject:

Re: Undefined constants

· Posted: 21.02.2014 - 13:39 · #7

why don#t you use the following:

asm
ldi _ACCALO, rom_adr_lowbyte
ldi _ACCAHI, rom_adr_hibyte
lpm
std vers_no, _ACCA
endasm;

to get one byte from the Program ROM memory without predefining the value of the ROM ??

Administrator

Gender:
Location: Germany
Age: 25
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002

Subject:

Re: Undefined constants

· Posted: 21.02.2014 - 14:01 · #8

@ Michael,
and it is still true, the main never can program the boot area without any code in the boot section which then does the real programming. For writing into any flash part, the SPM opcode must be used. But this opcode can only be executed in the boot area!

So with a completely empty boot you can never program any byte in the flash.

Quote

7.3.3 Boot Loader Section
While the application section is used for storing the application code, the boot loader software must be located in the boot loader section because the SPM instruction can only initiate programming when executing from this section. The SPM instruction can access the entire flash, including the boot loader section itself. The protection level for the boot loader section can be selected by the boot loader lock bits. If this section is not used for boot loader software, application code can be stored here.

@Merlin,
if you must exchange the bootloader by itself, you must have a dual bootloader in the boot area. The first one which must always be there should reside in a normally unused region of the boot. The second one which does the standard boot loader work should be placed on the start of the boot. If desired the application interacts with bootloader patcher in the top of the boot area and programs a new boot into the boot area, except of this initial loader. Please note that when doing this, the concerning boot flash pages must be erased page-wise. XMega128..256 pagesize = 512bytes.
A very good design is required to be bullet proof..

rolf

1
2
Page 1 of 2

Undefined constants

Extension to help with bootloaders

Undefined constants

Re: Undefined constants

Re: Undefined constants

Re: Undefined constants

Re: Undefined constants

Re: Undefined constants

Re: Undefined constants

Re: Undefined constants

Registered users in this topic