MC1322x: How to get memory dumps to analyze at failure state... and other tips & tricks

[AlanCollins]

It is possible to understand the Software state at the moment the node stops working. For this, you need to follow the next steps:

1. Identify which node is the one that stopped.
2. Connect the JTAG to that node. Make sure you connect the JTAG in a way the Vdd pin is connected first, so the device won’t RESET in the process.
3. Open IAR 5.50 and start debugging without downloading.
4. Once you are in the debugger window, you need to extract/dump the memory state into a .s file. à Right click in the “Memory” window. Then choose “memory save” option.
5. Choose Motorola or Motorola S19 as file format. Choose the memory address window you want to save: from 0x400000 to 0x417D00, you are including all RAM memory.

Now using the “.map” file, you may understand how the functions and variables were placed in the memory. This will be great help to understand what is going on within the sw stack.

[AlanCollins]

One of the important variables to monitor is the "MsgTrackingArray" which keeps monitoring of the internal message system. To enable this array in your code, you need to define MsgTracking_d, prior compilation.

See below the information you can get from the various messages used by the system:

typedef PACKED_STRUCT MsgTracking_tag

  {

  uint32_t MsgAddr;        /*Addr of Msg, not that this pointer is 4 byte bigger than

                            the addr in the pool has the header of the msg is 4 bytes */

  uint32_t AllocAddr;      /*Return address of last Alloc made */

  uint32_t FreeAddr;       /*Return address of last Free made */

  uint16_t  AllocCounter;   /*No of time this msg has been allocated */

  uint16_t  FreeCounter;    /*No of time this msg has been freed */

  uint8_t  AllocStatus;    /*1 if currently allocated, 0 if currently free */

  } MsgTracking_t;

So, if you hav ea problem becuase of memory allocation, you can understand exactly which fucntion is injecting the problem.