• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 630 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.

TMS320F28379D: printf stop working if trgmsg.c.obj is put into ti.ramfuncs or BINIT

Martin Otzen
Intellectual 912 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: TMDSCNCD28379D

Hi

I am trying to get printf send debug messages to CCS using C I/O (in this case puts() ).

Out of the box it also does work fine, but to avoid that it reserves one of my two HW breakpoints I want to move it to ram as suggested in Tips for using Printf.

If I do a simple

`.text:cio : { rts*.lib<trgmsg.c.obj exit.c.obj>(.text) } > RAMLS`

It still works fine in debug, but this program can only run from debugger, as it relies on the debugger to fill the allocated ram section with the CIO code.

Therefore i wanted to add it to the ti.ramfuns section so the code is copied to ram by call to device_init().

But then I get no more output in the console.

I can't figure out why this is the case.

- I have verified that the code is actually copied to ram.

- I have put a function of my main program into ramfuncs too, just to verify that I can execute code there.

- I can see in the memory view of the debugger that values is written to the __CIOBUF_

- I have verified in the map file that C$$IO$$ and C$$EXIT is indeed placed in RAM.

I the attached demo project, please notice two commented lines in the CIO_inRAM.cmd file

In the packed version printf does not work, and it looks like this:

   // Make sure the CIO relevant part is put into memory, to not block one of the two HW breakpoints.
   //.text:cio : { rts*.lib<trgmsg.c.obj exit.c.obj>(.text) } > RAMLS
   //.TI.ramfunc : {}
   .TI.ramfunc : { -l rts*.lib<trgmsg.c.obj exit.c.obj>(.text) }
   					LOAD = FLASH,
					RUN = RAMLS,
					LOAD_START(RamfuncsLoadStart),
					LOAD_SIZE(RamfuncsLoadSize),
					LOAD_END(RamfuncsLoadEnd),
					RUN_START(RamfuncsRunStart),
					RUN_SIZE(RamfuncsRunSize),
					RUN_END(RamfuncsRunEnd),
					ALIGN(8)

If you change it to

   // Make sure the CIO relevant part is put into memory, to not block one of the two HW breakpoints.
   .text:cio : { rts*.lib<trgmsg.c.obj exit.c.obj>(.text) } > RAMLS
   .TI.ramfunc : {}
   //.TI.ramfunc : { -l rts*.lib<trgmsg.c.obj exit.c.obj>(.text) }
					LOAD = FLASH,
					RUN = RAMLS,
					LOAD_START(RamfuncsLoadStart),
					LOAD_SIZE(RamfuncsLoadSize),
					LOAD_END(RamfuncsLoadEnd),
					RUN_START(RamfuncsRunStart),
					RUN_SIZE(RamfuncsRunSize),
					RUN_END(RamfuncsRunEnd),
					ALIGN(8)

It stops working, with the above mentioned limitation.

I am using the TMDSCNCD28379D Control board kit, and have tried using both and XDS110, and an XDS200. debugger.

I have not tried the builtin XDS110V2 thing, as neither this nor an available UART is present on my custom board where this ultimately must run.

Code Composer Studio  Version: 12.2.0.00009

  • 0
    Intellectual 912 points

    I have by now realized that the error is that I overwrite the break symbol, when i do the copy.

    I tried putting it as early as I know to do by using the BINIT table

       .text:cio : { rts*.lib<trgmsg.c.obj exit.c.obj>(.text) }
   					 LOAD = FLASH,
                     RUN = RAMLS,
                     TABLE(BINIT)

    But I still overwrite the estop0 symbol, how to do this correct?

  • 0 in reply to Martin Otzen
    TI__Guru**** 250340 points
    Martin Otzen said:
    how to do this correct?

    It is not supported.  This limitation is not documented because, I think, no one realized it.  The sequence of events is:

    1. CCS sets the breakpoint at the C$$IO$$ address
    2. CCS starts the program running
    3. The copy from flash to RAM happens, which overwrites the breakpoint at the C$$IO$$ address

    Unfortunately, there is no way to break or modify this sequence.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 912 points

    So the " Tips for using Printf." document recommends to put this into ram, but no one really tried it???

    Is there no way to preserve/restore these breakpoints?

    I can peek to see if they are sat before doing the copy, and avoid overwriting them. But I assume the debugger stores the original value that it replaced with the estop opcode, in this case that would be zero or ITRAP.

    Is there no way to access this breakpoint memory, to either update the stored value, or to just remove and reinsert it.either from the the scripting console or in the GEL file, either auto triggered or by a menu entry?

    Are you going to file this as a bug?

  • 0 in reply to Martin Otzen
    TI__Guru**** 250340 points
    Martin Otzen said:
    So the " Tips for using Printf." document recommends to put this into ram, but no one really tried it???

    What no one tried is allocating the functions in trgmsg.c.obj to flash for load, and RAM for run.  The recommendation in that article presumes these functions are allocated in the typical way, which means to the same address for both load and run.

    Martin Otzen said:
    Is there no way to access this breakpoint memory, to either update the stored value, or to just remove and reinsert it.either from the the scripting console or in the GEL file, either auto triggered or by a menu entry?

    No one has tried anything like that.  I am skeptical any of these ideas are practical.

    What would work is simply allocating these functions to RAM.  For instance ...

    .text:cio : 
{
    rts*.lib<trgmsg.c.obj exit.c.obj>(.text)
} > RAMLS

    Note this allocates the initialized section .text:cio to RAM.  That works when you load the program with CCS.  Such a system cannot somehow start running without CCS to load it.  That doesn't matter, because you also rely on CCS to handle the C$$IO$$ breakpoint.

    Thanks and regards,

    -George