[Microbit-Python] This happens when your code is "too big" (more than 8kB)

[Locard]

This is really cool James!

Just a quick one - those four bytes you're seeing. The first two are 
"magic" and denote the beginning of a MicroPython script (MP for 
MicroPython), and the second two tell the interpreter the length of your 
script so that it doesn't fall off the end. Importantly - they change 
between scripts!

As for where the extra data goes... the location mapped into memory 
immediately above the area that contains your code is the SRAM (starts 
at 0x200000000) - so perhaps it's getting flashed to there?

Locard


On 01/07/2016 10:15, James Sheppard wrote:
> Hello everyone
>
> I thought people might be interested to know what happens when the 
> MicroPython code being flashed onto a micro:bit is more than 8kB.
>
> This analysis was done on a hex file generated by the MicroPython 
> Editor on https://www.microbit.co.uk/ bulked out with ~200 lines of 
> comments.
>
> If you’ve never opened up a .hex file to take a look, now could be the 
> right time…
>
> (You might find https://en.wikipedia.org/wiki/Intel_HEX useful to 
> refer to.)
>
> The first line in the file looks like this:
>
> :020000040000FA
>
> Which sets the base address of data to be flashed to 0x0 0000.
>
> Lines then follow that start with
>
> :10XXXX00...
>
> which indicates the data to be written to 0x0 XXXX
>
> Keep going, and eventually you’ll see
>
> :020000040001F9
>
> which sets the base address to 0x1 0000.
>
> Then more data.
>
> Then
>
> :020000040002F8
>
> which sets the base address to 0x2 0000.
>
> Then more data.
>
> Then
>
> :020000040003F7
>
> (0x3 0000)
>
> and yet more data. So far this has all been MicroPython data (over 
> 200kB). Your code is next.
>
> You’ll see
>
> :020000040003F7
>
> again, which sets the base address to 0x3 0000 again (i.e. no change). 
> User code starts at 0x3 E000 with the bytes 4D 50 54 32 (“MPT2”) then 
> the script itself.
>
> :10E000004D505432...
>
> If there's more than 8kB of user code, you’ll see the address overflow 
> from 0x3 FFF0 to 0x3 0000
>
> :10FFF000...
> :10000000...
>
> During flashing of the hex file to the micro:bit, this causes the 
> MicroPython hex at these addresses to be overwritten - who knows 
> what’s just been trampled over!
>
> Cheers,
> James
>
> ----------------------------
>
> http://www.bbc.co.uk <http://www.bbc.co.uk>
> This e-mail (and any attachments) is confidential and may contain 
> personal views which are not the views of the BBC unless specifically 
> stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in 
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160701/2736b69e/attachment-0001.html>