Sorry for this but ...

General discussion on mikroC PRO for ARM.
Post Reply
Author
Message
orpheedulogis
Posts: 240
Joined: 16 Jan 2010 22:26

Sorry for this but ...

#1 Post by orpheedulogis » 07 Feb 2023 09:24

(Sorry because I repeat this question)
Is there someone to answer at this question: is it possible to write a bootloader in flash without datas coming from other areas.
Here I defined

Code: Select all

#define BOOTLOADER_START_ADDR    0x00C0 
#define START_PROGRAM_ADDR1      0x0500
#define ROM_SPACE_SECTION __attribute__((section("ROM_PROG1")))
#pragma makesection(ROM_PROG1, 0x700, 2048, CODE)


ROM_SPACE_SECTION will do exactly the same thing than Program1

Code: Select all

void Program1() org START_PROGRAM_ADDR1
{
    char Str1[10];
    strcpy(Str1,"BBBB");
    while(1)
    {
        delay_ms(250);
    }
}    


ROM_SPACE_SECTION void Program2()
{
    char Str1[10];
    strcpy(Str1,"DDDD");
    while(1)
    {
        delay_ms(250);
    }
}

When reading STM32 flash, I can see exactly the same datas at 0x700 and 0x500. I can suppose this is OK and prove the is no difference between using "makesection" or using "org".

But the problem is that "BBB" and "DDD" are in bootloader area , this will be unusable to update prog1 area without modifing bootloader.
Please tell me if you have a solution or not

Bootloader:

Code: Select all

void main() org BOOTLOADER_START_ADDR 
{
   char Str1[10];
   strcpy(Str1,"AAAA");

   Program1();
   Program2();
}

AntiMember
Posts: 136
Joined: 02 Jan 2020 19:00

Re: Sorry for this but ...

#2 Post by AntiMember » 07 Feb 2023 16:08

You can do as in the USB HID Bootloader example.
Write the Bootloader first, and then use it to write production code.
So your data will not overlap.
In other compilers, you will have to edit not only the code, but also the linker script.

orpheedulogis
Posts: 240
Joined: 16 Jan 2010 22:26

Re: Sorry for this but ...

#3 Post by orpheedulogis » 07 Feb 2023 16:54

AntiMember wrote:
07 Feb 2023 16:08
You can do as in the USB HID Bootloader example.
Write the Bootloader first, and then use it to write production code.
So your data will not overlap.
In other compilers, you will have to edit not only the code, but also the linker script.
Yes, I think about this: writing only the bootloader and try to compile only the main soft after.
But I can't use HID, the purpose is to do an update by air (gsm/bluetooth)
So can I be sure the compilation of a "program" zone (so without bootloader), with default adress, will be working if writed with an offest adress ?
Perhaps I'm not clear:

1) writing only bootloader
2) a new compilation for "program" only, so excluing bootloader, is done. That's mean it will be tested at first default adress
2) only by air (or serial port), a new soft is detected by bootloader.
3) bootloader write the new file starting at "program" adress but ... did the "program", compiled at phase 2, will use relative adresses for datas & other or not ? (if not it's useless)

AntiMember
Posts: 136
Joined: 02 Jan 2020 19:00

Re: Sorry for this but ...

#4 Post by AntiMember » 07 Feb 2023 18:52

I did not expect that the download would be via USB.
Even though it doesn't matter.
They put the bootloader at the end of the flash (orgall) and prohibit writing - changing this section.
With the directive orgall XXXX, the code and data will be from the address XXXX.
const unsigned long BOOTLOADER_SIZE = 128*1024; // Bootloader (this) code size.
// Must be the same as the size of
// flash sectors occupied by this bootloader!
// We'll place bootloader in last flash sector.
const unsigned long BOOTLOADER_START = __FLASH_SIZE-BOOTLOADER_SIZE; // Occupy last flash sector
..................................
// set write protection for bootloader sector
boot_code_sector = FLASH_AddressToSector(BOOTLOADER_START) / 8;
FLASH_OPTCR &= ~((1l << boot_code_sector) << 16);

// write option bytes
FLASH_OPTCRbits.OPTSTRT = 1;
while (FLASH_SRbits.BSY);

The main code is loaded from the address specified in the update package command.
And don't forget about RESET_VECTOR.
if (HidReadBuff[0] != STX) // Do we have an 'STX' at start?
// Each command must start with STX char.
return ; // No, then exit.

// Process received command.
CmdCode = HidReadBuff[1]; // Get command code.
Lo(GPAddress) = HidReadBuff[2]; // Get address lo byte.
Hi(GPAddress) = HidReadBuff[3]; // Get address hi byte.
Higher(GPAddress) = HidReadBuff[4]; // Get address higher byte.
Highest(GPAddress) = HidReadBuff[5]; // Get address highest byte.
Lo(GPCounter) = HidReadBuff[6]; // Get counter lo byte.
Hi(GPCounter) = HidReadBuff[7]; // Get counter hi byte.

orpheedulogis
Posts: 240
Joined: 16 Jan 2010 22:26

Re: Sorry for this but ...

#5 Post by orpheedulogis » 07 Feb 2023 19:00

Thanks a lot !

I will try this

AntiMember
Posts: 136
Joined: 02 Jan 2020 19:00

Re: Sorry for this but ...

#6 Post by AntiMember » 07 Feb 2023 19:24

I would still use the flag of an unfinished flash recording (power failure, for example).
And remained in the bootcode.

orpheedulogis
Posts: 240
Joined: 16 Jan 2010 22:26

Re: Sorry for this but ...

#7 Post by orpheedulogis » 10 Feb 2023 07:57

AntiMember wrote:
07 Feb 2023 19:24
I would still use the flag of an unfinished flash recording (power failure, for example).
And remained in the bootcode.
Of course, if it work, I will use many tests to be sure datas are not corrupted.
Thanks
(I hope to start tests today)

Post Reply

Return to “mikroC PRO for ARM General”