Update on status of offline IDE

Oh how stupid I am, RTFM !

https://os.mbed.com/cookbook/Compiler-Error-L6406E

or… maybe not

Maybe you could make the execution region a little smaller, and then put the key in a separate region.
Then having the stlib at the end of the execution region wouldn’t be a problem.

1 Like

Thats what I’ve ben trying to do for the past 1.5 hours.

It seems I need to understand how the .ANY selector operates. My key gets pulled there (?) and the same overflow occurs.

Yet another example where well-documented open-source GCC is better than proprietary Keil ARMCC

Oh well. I will just move the key like @catsfolly suggested. It means we’ll have to recompile all binaries… which is NOT a good thing but maybe can’t be avoided

Out of interest, have you tried different programs at all?

Everywhere I’ve found a report of the error the solution seemed to be “you’re using more memory than your device has” so I’m wondering if maybe a specific program is using close to the memory limit.

That or maybe introducing a second IROM section if possible?
I notice some places use an IROM2.

(I’m literally just guessing now.)

1 Like

No I am sure this is because of some linker settings. There is plenty of room in the binary, I can see the situation if I drop the key. The linker adds this mysterious function always at the very end. It is exactly 0x58 bytes in size. I can see the bytes.

The problem is the ARMCC compiler and its command line switches are a “black box” in the online compiler. So I really can’t figure out why and where this thingmajogic is specified. It is some ARMCC core libraries - the source code of which is not visible

1 Like

One last idea.

When you’re saving the version and address, are you saving them as a struct? I.e. do you have (for example) a struct BootData or a class BootData that you’re using to store the values? (If yes, post it.)

1 Like

No. Its just a table of const chars.

If it was only a few bytes, I would suspect alignment/padding/veneers.

But the overflow is 0x58 bytes. So its the linker putting something extra in.

I am sure the culprit is the .ANY selector as it can “assign any unassigned sections to that region”

In other words, there is some section defined in core libs that is unassigned until we come to the final .ANY selector, and it gets put in last.

I was indeed wondering if maybe struct packing/padding was the problem. Glad to see you know about that though, you’re evidently an experienced programmer.
I didn’t know about veneers, ARM is an interesting ISA.

My last thoughts before I leave for the night:

Some places used a * selector instead of the .ANY selector.
I wonder what happens if you try to place the values at (0x3FFF4 - 0x58).

Sorry I couldn’t be more help, I might know a lot about programming and C++ but I have a lot to learn about ARM and/or Keil it seems.

So you tried something like this:

LR_IROM1 0x00000000 0x40000  {    ; load region size_region (228k)
  ER_IROM1 0x00000000 0x3FFF0  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
 ER_IROM2  0x3FFF0  0x10 { 
   *(.ARM.__at_0x3FFF4) ; key
  }
  ; 8_byte_aligned(16+47 vect * 4 bytes) = 0x100
  ; 32kB (0x8000) - 0x100 = 0x7F00
  RW_IRAM1 (0x10000000+0x100) (0x8000-0x100)  {
   .ANY (+RW +ZI)
  }
}

(warning - I don’t know anything about keil files…)

1 Like

Yes, I tried that exactly. Same result

I am pretty sure I am against this:

http://www.keil.com/support/man/docs/armlink/armlink_pge1362065993681.htm

AHHAA! But what if I specify another .ANY in the ER2 region? Only the table CAN fit there…

Here goes another try:

LR_IROM1 0x00000000 0x40000  {    ; load region size_region (228k)
  ER_IROM1 0x00000000 0x3FFF0  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  ER_IROM2 0x3FFF0 0xF {
	.ANY (+RO)
  }
  ; 8_byte_aligned(16+47 vect * 4 bytes) = 0x100
  ; 32kB (0x8000) - 0x100 = 0x7F00
  RW_IRAM1 (0x10000000+0x100) (0x8000-0x100)  {
   .ANY (+RW +ZI)
  }
}
1 Like

One more try. Custom assembler file and INCBIN directive. If that does not let me put the key at 0x3FFF4 then I’m moving/disabling the key entirely

1 Like

Can’t use INCBIN, online compiler doesn’t accept.

So end result is key will be moved to 0x3FF00. That works

All of your binaries are therefore not loadable from now on. This will be fixed gradually, I will put new binaries online and update everything.

1 Like

Success!

I have just made online mbed compiler work with the loader. This means online IDE will no longer broken bins that crap your Pokitto, and you have one less thing to worry about.

I can now proceed to unify the online (mbed) and offline (EmBitz) codebase so that they will keep in sync.

This was not an easy thing to do:

  1. I was not able to keep the key where I originally had it because online IDE was putting some function after the key, no matter what I tried. This is caused by the fact that RW init data is ALWAYS placed after RO data in load region. I couldn’t find a way around it.

  2. mbed online compiler does not allow inline ASM. I didn’t want the codebase to have ASM files that are used online but not offline. So I had to whip up some C to circumvent the inline ASM.

When you look at this bit of code below, you’ll understand why these things can throw up some surprises and make the progress slower than intended.

So, Tomorrow: offline IDE… finally.

#ifndef __ARMCC_VERSION
asm(" mov r0, %[address]"::[address] "r" (app_link_location));
asm(" ldr r1, [r0,#0]"); // get the stack pointer value from the program's reset vector
asm(" mov sp, r1");      // copy the value to the stack pointer
asm(" ldr r0, [r0,#4]"); // get the program counter value from the program's reset vector
asm(" blx r0");          // jump to the' start address
#else
uint32_t *app_loc = (uint32_t*)app_link_location;
__set_MSP (app_loc[0]);
((func_t)(app_loc[1]))();
#endif
2 Likes

To try the latest version I’m working on (includes loader)

Import this “Pokitto” library to your program:

https://os.mbed.com/teams/Pokitto-Community-Team/code/Pokitto/

Note:

Do not import mbed-src anymore! This library contains it!

2 Likes

I’m guessing that’s supposed to be a security ‘feature’, but it’s a pretty silly one.

Out of interest, what is func_t defined as? using func_t = void (*)(void)?

#ifdef __ARMCC_VERSION
typedef void (*func_t)(void);
#endif
1 Like

It’s up now

1 Like

Ah, good to know.

Functionally that typedef's equivalent to my guess, so good guess, I guess :P.