How can I write to a file on the host from my RM48L950 hercules usb stick target?

Mark,

Are there any data written into the file? I would suggest you inserting breakpoints at fprintf()and fclose() calls and see if they can complete. You may also need to check your link command file to see memory settings match your device. If you enabled ECC, disable it for the time being. There are two possible causes for data abort: (1) uncorrectable ECC error and (2) accessing invalid memory space.

Thanks and regards,

Zhaohong

Mark,

Does your linker command file have a sections directive for the .sysmem section? (Heap).

I tried inserting your code into the main of a HalCoGen project I had,  also got a data abort, and found that the problem was

.sysmem was not specified and by default was being linked into Flash.    Since you can't really use Flash as a heap (not writeable)

this creates problems.

Here's what the SECTIONS directive looks like for me now:

SECTIONS
{
    .intvecs : {} > VECTORS
    /*.tovly : {arm_fir_f32.obj(.text)} load = FLASH0, run = RAM, table(_ctbl1) */
    .text    : {} > FLASH0 | FLASH1
    /* .ovly    : {} > FLASH0 | FLASH1 */
    .const   : {} > FLASH0 | FLASH1
    .cinit   : {} > FLASH0 | FLASH1
    .pinit   : {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM
    .sysmem  : {} > RAM

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

And I was able to see the file created (it gets created in the Debug subdir.  [or Release subdir, if you are building a release configuration])

and has the expected:

n = 0
n = 1
n = 2 ....

up to n = 19.

Some tips here on debugging in case this doesn't match what you see exactly.

1) If you halt the processor in the data abort routine that comes with HalCoGen, you can step

through the default handler.   If you get past the ramError and flashError checks and continue to

this instruction:

        subs    pc, lr, #8            ; restore state of CPU when abort occurred, and branch back to instruction that was aborted

Then you are at the end of the handler and about to return to the instruction that caused the data abort in the first place.

You can hit 'assembly step' one more time and you will be exactly on the instruction that caused the abort, with the

registers restored to the state they were when the abort occurred.   For me I was able to see that there was a load

from [R2] where R2 was 0xFFFFFFFF ...  not in the valid memory space for RAM or flash and the value equates to

erased flash... so this was the first clue.

2)  in this case, the routine that I returned to was 'memory.c' but the source could not be found.   This is because it

is part of the runtime support library.

 If you go to your compiler directory, there is a .zip file (rtssrc.zip).

On my PC this is in the folder:  C:\TI\ccsv5\tools\compiler\arm_5.1.0A12342\lib

You can unzip this file into that folder and you will have a subdirectory  C:\TI\ccsv5\tools\compiler\arm_5.1.0A12342\lib\rtssrc

Then in the debug view in CCS you'll see that the source window has a 'Locate Source' button.
You can browse to the folder where you unzipped the runtime library and it'll find the source for memory.c

That at least helps you understand what's going on,  scroll through the file and see it's using the heap.

Then the obvious thing to do is check where the heap is linked.

3) In retrospect, the compiler was issuing warnings about .sysmem size and Sections directive not being specified.
So this actually was an early indicator of the problem.

Anyway, those are just some tips.

The long term soln. I think is we need to include .sysmem in the linker command file that comes with HalCoGen.
I'll submit a ticket on that issue.

Best Regards,

Anthony