No announcement yet.

[FLASH Mode] Dinamic memory allocation Trouble

  • Filter
  • Time
  • Show
Clear All
new posts

  • [FLASH Mode] Dinamic memory allocation Trouble

    During writing the code for my project I was always using the RAM Mode for debugging and testing. Once the code was completed I wrote the program into the FLASH Memory. To my great surprise and disappointment, the same program, which ran correctly and without any problem in RAM mode, had a problem at the begin of running: the well know MEM TRAP. After spending hours to try to detect the problem, I could find that the problem was coming from the memory allocation which I used to define some data structures.

    This memory allocation has a different behavior during the first calls of mem_Alloc (it's the same for AllocZ and AllocV). During RAM mode, the memory block, created by mem_Alloc, has always an address which starts from 0x3Fyy and goes down with the successive memory allocations. With the following addressing, no trouble occurs and the code works fine. When the program is saved into the FLASH memory, the first memory allocations have a strange address (0x4000 and so on) and, after a few allocations, the addressing is working as the RAM mode. When a memory block has "the strange address" the data contained into it are corrupted. If this block contains references to other memory location, the soup's on.

    I wrote an example which is showing this behavior and I attached it to this post.

    Any explanation? Where can I find information about what is behind the memory allocation and addressing definition?

    used IDE: Workshop4 v4.5.0.17
    Attached Files

  • #2
    I'm not sure what is causing your mem trap, as the example doesn't show this.

    But the example does show a real issue which needs to be fixed.

    Diablo only has 16KB of RAM, at addresses 0-0x3FFF.

    When you raise a string pointer it, effectively doubles the address, hence a string pointer can be 0-0x7FFF.

    So whilst you can effectively address RAM above 0x3FFF, a string pointer to any address beyond 0x3FFF will not work, as it will effectively be addressing program Flash.

    Since it appears that there is 16 bytes of this spurious RAM, an 'ignored' allocation of 16 bytes should be an effective workaround.

    We will update this thread as we work our way through this bug that has somehow gone unnoticed for quite a few years.


    • #3
      Thanks for your reply.

      About my MEM TRAP error, it is strongly related to this bug. As I explained, I created dynamically a data structure which contains some pointers to other code-blocks and data-structures. When this data-structure is created as the first one, because of the bug, the pointers have a wrong assignment and this causes the MEM TRAP error. The workaround works when this bug happens only during the first memory allocation. However, if this bug happens again during runtime, after memory allocations/deallocations, the workaround does not help anymore.
      Since my code is still under testing, I case I'll find more information to this bug I let you know.



      • ESPsupport
        ESPsupport commented
        Editing a comment
        As I said above, if you allocate the spurious 16 bytes and do not use it (specifically in a string pointer), or free it (such that it can be reallocated), then you should not see the issue.