watching dynamically allocated variables under HiWave

[mroczeks]

Is there a way to watch dynamically allocated data under HiWave?

I am trying to observe dynamically allocated structures (with malloc instruction) inside Data windows of HiWave.

I tried Options > Pointers As Arrays... option under right-click menu but it is not suitable for sturctures.

[NavidadRedivivu]

It is most probably related to optimizations. For S12X for instance, malloc most likely returns in the D register (banked memory model, no LIBDEF_FAR_HEAP_DATA defined, and so on), and unless forced to do otherwise the compiler will not allocate a stack location to spill this register. If this is the case then no, you will not see the proper location in the debugger. You can check the value of the returned pointer from malloc (check the compiler manual for the calling protocol for the exact MCU/derivative you are using). Then you can go in the memory window and see what's stored at that location. I don't know for sure if hiwave supports adding user defined types if you add an expression to the 'Data' window. Another thing you can try is to disable the optimizations. On S08 you get a -O0 option, but I doubt it will work in this case. On S12, you need to individually disable the optimizations. If you are targetting ColdFire, I don't know  .

However, if your pointer is stored in a global variable, it should work since it has to be written back to memory sooner or later. Risking to start a debate: why are you using malloc anyway on this small micros (assumming S12/S08) ? 

[mroczeks]

Thanks for posting. I am using S12XE devices. All optimizations are disabled in CodeWarrior options.
I already tried expressions (casting and stuff) inside Data window but I can't get it working or doing something wrong.
Getting elements of structure works inside Data window but it does not with pointers.
Any other ideas?

Starting debate ...
Why not to use malloc/calloc? The smaller the uC the bigger the need for memory utilization, isn't it?
I need to do some task involving lot's of data during startup to initialize my app and then I don't need it anymore.
That's one of the reasons for malloc.
Another is when you want to write closed library.
Then I just return pointer so that user of library is isolated of library implementation details.

[Lundin]

The only reason to use malloc is runtime changes in the middle of execution, of a very generic nature. If you are merely using malloc for various startup data, you might as well skip malloc entirely, use the memory you would have used for the heap as extra stack size instead, and allocate everything temporarily on the stack. Much faster and much safer.

[NavidadRedivivu]

Apart from what Ludin and kef already mentioned, I would also point out that you'll have additional code linked (malloc and whatever functions and variables it relies on, if any). So using malloc basically leads to a slower application, which uses more RAM and flash. Of course, you know your application best, so you can tell if you can spare the additional resources.

[kef]

How is your pointer defined? Pointer type should tell debugger what's under address, pointer is pointing to.

typedef struct{   int aa;   int bb;} type;type * uio;struct{   int xx;   int yy;} * zzz;int foo(  struct{int xx;int yy;} * zzz ){   zzz[4].xx = 5;}

 All ^^ these pointers are perfectly inspecteable in debugger. If it's pointer to array, you can specify array size using Options->Pointer As Array. It works.

Regarding malloc and your library. It would be the best to allow your user to choose where to allocate your temporary array. Tell you need 100k of RAM for initialization calculations. You tell user to call Init(void *x) with x pointing to that big chunk of RAM, which user can use for any purpose afterwards. In this case user will have at least 3 choices. 1) to use malloc, 2) to allocate it statically or on the stack, take address and pass it to init routine 3) after initialization reuse this RAM for users variables. Using malloc user has to reserve enough RAM for the heap, this doesn't differ a lot from static allocation. Malloc doesn't save any single byte of RAM, quite the opposite, it requires additional variables to maintain RAM allocation, deallocation etc.  What about RAM fragmentaion, after several alloc/free calls? You need much more RAM if you are going to use primary purpose of dynamic allocation, else your code will stuck at malloc returning NULL, because heap is fragmented...