• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 568 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.

28335 loading RAM for debugging fails when GPIO34 is low

Jan Stefan
Intellectual 275 points


Micro 28335 with RAM in Zone 6

CCS 4.2.0

XDS560V2 USB JTAG

I recently started to use GPIO34 and ran into problems loading my RAM debug image which has run fine for months. 

It seems the CCS Debugger or perhaps the JTAG Loader assumes GPIO34 is configured as the XINTF XREADY input rather than a general purpose input.

When GPIO34 is low, the RAM loading fails (I will attempt to attach a screen). 

Nether my code or the CCS gel script configures the GPIO34 as XREADY, nor do we want or need an XREADY signal.

Is there some way to configure the CCS RAM loader to not assume GPIO34 is an XREADY input but that the bus is always ready?

TIA,

Jan

 

  • 0
    TI__Guru 64600 points

    Would you be able to provide a listing of the contents of the XINTF registers and how they are configured once you have connected to the target?

    I'm not aware of CCS modifying the behavior of the XINTF with the exception of what the included GEL scripts have done.

  • 0 in reply to BrandonAzbell
    Intellectual 275 points

    FYI I am using 16 bit RAM not 32 bit

    XINT regs after connect, prior to load

    XINTF

       XTIMING0 0x0043FFFF

       XTIMING6 0x0043FFFF

       XTIMING7 0x0043FFFF

       XINTCFG2 0x003F

       XREVISION 0x0005

       XRESET 0x0000

    GPIO

     GPBMUX1 0xFFFFFFC0

    I don't believe the problem is with the XTNTF registers. I believe the utility code that loads my debug RAM image from Bullitt_RTC.out into external RAM on my target is confused. Part of my problem is that I do not know what code actually loads a debug image into External RAM. It might be CCS or an algorithm or a spectrum digital JTAG driver or something else.

    Correct me if I am wrong:

    "I believe the XReady signal comes from the External RAM chip into the XINTF interface. I believe that if GPIO34 is configured to XREADY, that the XINTF reading and writing can be delayed until the chip sets the XReady signal high".

    That being said, My chip does NOT have an XReady output and I would not configure GPIO34 to XReady. GPIO34 is actually attached to a bubble detector device that can drive the pin low.

    With the bubble detector removed (GPIO34 pulled up by default), My debug image loads fine and has been loading fine for the past few months..

    With the bubble detector attached and no bubble present(GPIO34 High), My debug image loads fine.

    With the bubble detector attached and a bubble present(GPIO34 Low), My debug image load fails.

    A CCS pop up displays:

       Error Launching Debug Session

       You may continue with your debug session if you wish to resolve the issue by performing such tasks as power cycling the device or editing your startup scripts.

       Continue launching?

    The console displays:

         C28xx: File Loader: Data verification failed at address 0x001004FF Please verify target memory and memory map.
         Error found during data verification.
         Ensure the linker command file matches the memory map.

    I believe the program loading my debug image is using GPIO34 as though it were an XReady signal. When the bubble detector holds it low the loading fails. When the bubble detector holds it high it succeeds.

    You should be able to recreate my problem by forcing GPIO34 low and attempting to load a RAM debug image.

    Thanks,

    Jan

     

     

  • 0 in reply to Jan Stefan
    TI__Guru 64600 points

    Based on the values of the XINTF registers that you have provided, the XREADY input signal is in fact being used.  For each of the Zones, Bit 14 of the XTIMING* register is the control bit called USEXREADY whereby a logic-1 configures the XREADY signal to extend the active portion of an access to the zone.  This is detailed in the XINTF user's guide (SRPU949) in Table 8 on page 24.

    You should also look at the System Control and Interrupts Reference Guide for details about the GPIO module.  Specifically, look at Figure 43 on page 64 that shows how despite the fact that you may be using GPIO34 as a GPIO, the state of the pin is actually used for the XREADY signal to the XINTF.

    This would be consistent with the behavior you are observing.  Firstly, the XINTF is being configured to use the XREADY signal to extend an access.  And when the pin of the device is being held low, issues are arising.

    I would suggest setting bit 14 of the XTIMING* registers to logic-0.

  • 0 in reply to BrandonAzbell
    Intellectual 275 points

    Spot on! as usual,

    Thanks Brandon

    TI is lucky to have you. 

    Jan