Strange things happening with `E.compiledC`

Posted on
  • Hi,

    I tried E.compiledC on my Bangle 1 2v16 and see weird things happening. After "Resetting without loading any code", the following

    var c = E.compiledC(`
    // void init()
    // int f()
    
    volatile int a;
    
    void init() {
      a = 0;
    }
    
    int f() {
      a++;
      return a;
    }
    `);
    
    c.init();
    setInterval(() => print(c.f()), 100);
    

    gives me

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    1644167202
    1644167203
    1644167204
    1644167205
    1644167206
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    268435505
    50
    51
    52
    53
    54
    55
    1811939384
    57
    58
    1761607739
    1761607740
    1761607741
    1761607742
    1761607743
    1761607744
    1761607745
    1761607746
    

    Prior to that I ran code which wrote to RAM locations where it shouldn't have. So I rebooted and reflashed the firmware hoping it would reset the device and resolve the issues I see. Is there anything I can do? Its a bit scary to run code that might modify any RAM location at any point.

    Thanks in advance!

  • No need to reflash firmware, just rebooting is enough (E.reboot or holding btn1+2), firmware is in flash not ram so you cannot corrupt it by changing ram.

    btw you don't need the variable to be volatile. from the sequence it looks like it is incrementing but sometimes the highest byte of the a variable is corrupted. Oh, I think I remember this bug, try to declare it with initialized value like

    volatile int a = 0;
    

    that should be safe. Uninitialized variables go to .bss section and that one is not part of the preallocated binary array in RAM so it will corrupt something after the array. It is a bug (or feature) of the compiler.

    Or you can put global variables to .text segment, that will work too and will even generate a bit smaller code

    __attribute__((section(".text"))) int a;
    
  • Thanks, good to know about the reset. Was using a custom build to try things, so reflashing wasn't wasted effort at least :)

    Regarding initialized or not, I tried a few variations and it seems that volatile is the culprit. Without it, the counter runs to at least 2000 whether or not it was initialized during declaration. Just initializing didn't fix it. The reason why I used volatile was because I read it here http://www.espruino.com/InlineC.

    I'll keep the optimization in mind :)

  • Oh, forgot that initialization to zero goes to bss segment too, so either the attribute or try =1. volatile should not matter in that code you wrote, you don't access a variable from interrupts. That example possibly uses it because of setWatch with irq:true (?).

  • You are right, and I was wrong. When I removed volatile in the actual application, the issue was still there. After that, initializing with 1 did fix it in the example as well as in the application (... I hope). Thanks a lot!!

    Probably worth to mention somewhere xd

  • Probably worth to mention somewhere xd

    It is a bug so I reported it as https://github.com/gfwilliams/EspruinoCo­mpiler/issues/15

  • Thanks - I'll get a fix in for this soon

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Strange things happening with `E.compiledC`

Posted by Avatar for !evil @!evil

Actions