• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 965 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

The illegal address access will be generated in calling the standard c lib function -- add_device

tony chen
Intellectual 430 points


Hello,


Currently I am migrating our old product from 2812 to 28335 control board.
When the firmware executes the following function

void vInitSerialRedirect(void)
{
add_device("serialout", _SSA , iSerialOpen, iSerialClose, iSerialRead, iSerialWrite
, iSerialLseek, iSerialUnlink, iSerialRename);
freopen("serialout:", "w", stdout); // redirect stdout to sci
setvbuf(stdout, NULL, _IONBF, 0);
}

The illegal address access will be generated in add_device. In fact these codes had been used for a long time
in 2812 and our 28335 evaluation board.
This time, the differences are : we added more codes, and changed the CMD file to support DMA and FPGA.

By puting vInitSerialRedirect() in the first line of main(), and run, the result is the same, which means
the illegal address access is not caused by the other codes, in stead, it may be due to the memory config,
compiler config, or compiler related staffs.

I attached a picture to show this issue in which the XAR7 was loaded an illegal address value from @0x3e
and cause the crash.

Also the cmd file was attached.

2818.ProductDSP1_Input.zip

  • 0
    TI__Guru* 84285 points

    That instruction is using DP-relative addressing.  It's not loading from 0x3e, it's loading from ((DP<<7) + 0x3e).

    The address it's loading from is probably _lock, which should be initialized to point to the function _nop.  Make sure that the variable _lock is initialized before add_device is called.  In ROM model, this initialization is performed by auto_init.  Are you using ROM model or RAM model?  Are you calling vinitSerialRedirect before main starts?

    Make sure you have plenty of stack and heap space.

  • 0 in reply to Archaeologist
    Prodigy 180 points

    Hi Quote,

    Thanks for your reply, and with your help, I successfully found the problem's root cause which was due to our

    board's external ram pin connection problem ( most of our ebss was allocated there).

    B&R

    tony