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.

XDS100 V2 debug error for LC4357

Other Parts Discussed in Thread: HALCOGEN

Hello,

I am having the following error message from CCS when debug

CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR5: GEL Output: Memory Map Setup for Flash @ Address 0x0 due to System Reset
CortexR5: Can't Run Target CPU: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 5.1.507.2)

Running CCS6.0.1, XDS100V2 14 pins from spectrum digital.

I found a discussion @ e2e.ti.com/.../395937

But I am not sure is the same questions is addressed/solved or not.

My JTAG connection where PS5 = 3.42V.

Thanks

  • I don't think this is related to the questions on the forum re. the 10 pin header - if you have a 14 pin header on your board.

    This page  may be helpful - especially the DBGJTAG utility near the bottom.

    To me it sounds like your scan chain is ok (but you should confirm no break etc.. ) but there is something preventing one of the cores from being accessed.     Anyway try the stuff on the page and let us know if you can confirm you chain is intact.

  • Here is what I got:
    --------------------------
    This path-length test uses blocks of 512 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 6 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.
    .........
    The JTAG IR Integrity scan-test has succeeded.
    ......
    The JTAG DR Integrity scan-test has succeeded.
  • Hi Ning,

    Then your scan chain is in tact - which means the error is due to a problem in the on-chip logic.
    This could be as simple as the CPU being held in reset. Or the CPU may have booted but run some code
    that puts it in an endless error loop or shut off it's clocks - making it more difficult to attach a debugger to.

    You can try showing all cores and connecting to IcePick instead of the CPU. Then you can try issuing a
    system reset through the ICEPICK connection and see if this can kick start the CPU connection.

    Or you can check your hardware to make sure reset, clock, etc. are good.
  • Hi, Anthony,

    I did the following steps

    1) in debug config setting, enable "Synchronize the properties for all compatible CPUs". then I picked ICEPICK_C in program panel.

    2) kick off debug and here is the screen shot

    3) connect all targets and then show all cores.

    I am not sure how to issue a system reset there but it seems that CPU is staying at address 0x4 (out of fab code?)

    The nPORRST is 1.8V with 3.4V VDDIO supply (designed this way, current ~= 100uA to nPORRST pin), VDD = 1.19V, Vflash/adc = 3.3V. nRST and nERROR pins are 3.4V. 

    My osc is set at 20MHz, though, not 16MHz by defualt in CCS. I will scope my CLK later.

    Thanks

  • Ning,
    FYI the VIH min on nPORRST is 2V - so 1.8V is out of spec. It is probably not causing a problem for this debug - since you can connect.

    If your CPU is sitting at address 0x04 then that is due to an exception vector - for the UNDEF / undefined instruction exception.

    You should be able to issue a system reset from CCS and put the CPU back to adress 0x00000 (reset vector).

    In any case you are connected in the 2nd screenshot because the Cortex R5 is not showing an 'x' (like the non-debuggable devices show in your first screenshot). In the 2nd - your connected to all cores and so you're in control.
  • Anthony,

    Do you have any example PROJECT (not the C example code) based on CCS6.1.0.00104 for me to try?

    Thank you

  • Hello,

    I scoped the OSCIN pin and it is 20MHz sin wave, swinging from 0V to 2.24V. The OSCOUT pion is 20MHz too and swinging from -0.4V to 2.2V.

    I think the hardware is fine. Maybe the issue is the software configuration. So it would be nice to have a working proof project to try.

    Can you send an example project to test it out?

    Thank you, 

  • Ning,

    There are example projects that come with HalCoGen.
  • HalCoGen only have example CODE, not project.
    Nevertheless, I did use HalCoGen to generate an example project, loaded it at CCS, compiled fine but still have the same issue during debug.
    It would be nice to have an exising CCS project already proven at the given environment/configuration.
    Thanks,
  • Ning,


    Did you see the video from Jan Cumps?   It would help you a lot.

  • Anthony,

    Yes, the link cmd part is really helpful. I followed the procedure exactly, however, I got the same error message as before.

    It failed when trying to erase FLASH. I checked the VCCP supply and it is indeed 3.3V while the core is powered at 1.184V.

    Well, I am using XDS100v2 and my oscin is 20MHz though.

    Thanks

  • Did you remember to change the flash settings in CCS? (uncheck auto-gen ECC, uncheck verify, etc...)
  • Anthony,

    Do you know anyone in Dallas who has the lunchpad development kit in your video? I'd like to borrow one for now. Just want to check my connection.

    I will order one as well.

    Thanks

  • Nope. But they're available to order.
  • Anthony,
    Just want to confirm with you that if VCCP is not powered properly, Flash won't be readable, right? I can read, but not program/erase flash.
    Thanks
  • No idea, that's out of the recommended operating conditions of the device. You shouldn't do that.
  • I just want to confirmthe that the issue is not caused by VCCP. So I am hoping if I can read the Flash, then the VCCP is fine.
  • OK, more update here
    1) I tried to play TMS570LC43x LaunchPad and I can erase/program the on chip flash --> this indicate my CCS setup is correct
    2) I modified the board so that the nPORST pin stays at 3.3V after power on
    3) I scoped the Vddflash supply while CCS was trying to load the program and I don't see any voltage fluctuation
    4) I have few people from MCU lab in Dallas to check the board but no finding so far.

    One thing I haven't tried is to use this XDS100v2 on other MCUs. I doubt the emulator is the root cause since the JTAG connection test passed.

    At this point, I am clueless.

    Full error message attached below

    CortexR5: Can't Run Target CPU: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 5.1.641.0)
    CortexR5: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.641.0)
    CortexR5: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.641.0)
  • Ning,

    If you're having trouble with your XDS100v2 connecting - there is a list of things to try here:
    processors.wiki.ti.com/.../XDS100

    But I wouldn't necessarily conclude that your CCS setup is correct, if the XDS110 works. They are different emulators (110 and 100v2). Also I wouldn't rule out a problem with your board or the 100v2.

    -Anthony
  • Did you remember to change the flash settings in CCS? (uncheck auto-gen ECC, uncheck verify, etc...) <-

    then why do you uncheck auto-gen ECC , uncheck verify ?

  • Yes, I did. I have the exact same project that can be loaded to TI launchpad, but not my own board (exact same chip).

  • Did you find your issue? I'm having the same issue!