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

CLA of 28069 won't start up without emulator

John Bennett
Prodigy 110 points


Hi folks,

      I've made up a PCB with a 28069 on it an all appears to work fine with the XDS connected. However if I load the program, remove the emulator and re-apply the power then it doesn't work properly.

The main core appears to be running as I/O related to that is working, however the CLA isn't doing anything, or rather it's not firing it's interrupt once finished (as I have other main CPU tasks triggered by that and they're not doing anything).

Am I doing something wrong in the programming procedure? I've also messed around with TRST and the XRS pins, but it has no effect.

This is the 5.2 CCS with the C compiler for the CLA. I'll have to go back and try a project with an ASM compiler. On that matter, how does the C code copy across the program memory for the CLA, as it's commented out in all the examples, but still works (with the emulator anyway)?

I've also tried putting a delayed CLA initialisation in the code (let the PWM and A/D's run a bit first), but it does nothing. I also tried doing a hard reset in code, but the CLA doesn't recover from it, even with a reload of all the registers (with the emulator connected, I'm trying this obviously)???

Any advice much appreciated. This is a late discovery for me on a piece of work, so I'm panicking a bit.

Regards,

         John

 

  • 0
    Prodigy 110 points

    Aargh, I think it's to do with the BOOT pins, TDO and GPIO34. They're unconnected, as my circuit is now, so it must be semi-booting tfrom flash.

    Is there any way to force it to boot to flash in code, and ignore the state of these two pins? Otherwise it's a microscope and fine wire job for me...

     

    If they're fixed and the ROM can't be changed, then why not mark them as 'BOOTSEL' it on the pin schematics to distinguish them?

     

  • 0 in reply to John Bennett
    Prodigy 110 points

    Running out of ideas now :-(

    The CLA appears to run a code branch once, then freezes. The main CPU runs fine. A watchdog reset won't even kickstart the CLA. into life.

    I've got TDO and GPIO34 pulled up to 3V3, as in the Control Card.

    All 100% good when programmed from an emulator, but not when powered without.

     

  • 0 in reply to John Bennett
    TI__Mastermind 43730 points

    Make sure the CLA clock is enabled, in your code..

    the emulator will do that for you however when running from flash this might not happen

  • 0 in reply to Manish Bhardwaj
    Prodigy 110 points

    Hi,

       thanks for the suggestion. Unfortunately it is enabled - I use F2806x_sysctrl.c to enable everything. I also added code to make sure, but it made no difference. I figured the clock must be running for it to run the CLA code loop once (I made a test routine where the CLA does some incrementing PWM outputs). I've tried manually triggering the CLA but it still only runs the once.

    Just curious - where is the code loaded to the CLA when you compile for it in C? Regardless, I figured it is being loaded as it runs once.

  • 0 in reply to John Bennett
    Prodigy 110 points

    Ok, just tried a Control Stick  and that doesn't work either (I power it from an external 5V and program it with an external programmer via the JTAG header). Boot pins are both set to ON. Works fine when emulated, no CLA without.

    I was wrong about the CLA - I don't think it's running at all. Sorry for the confusion, my test code wasn't making it very clear.

    For what it's worth, all chips are TMX variants, but then I suspect you'd have heard of this if it was a hardware problem. Wonder if it's to do with the code getting loaded onto the CLA (or not).

  • 0 in reply to John Bennett
    TI__Mastermind 20850 points

    John,

    It sounds like the CLA code isnt being copied over to its programming space i.e. RAML3. Here are a few things to check:

    1. If you are running in standalone mode(no emulator) make sure the Cla code is in a section "Cla1Prog" and make sure that this section is allocated as follows in the linker command file:

       Cla1Prog        : LOAD = FLASHx,
                         RUN = RAML3,
                         LOAD_START(_Cla1funcsLoadStart),
                         LOAD_END(_Cla1funcsLoadEnd),
                         RUN_START(_Cla1funcsRunStart),
                         LOAD_SIZE(_Cla1funcsLoadSize),
                         PAGE = 0

    Here FLASHx is any available FLASH block

    2. In either your main.c or header file thats shared with the CLA and the C28 place the following:

    extern Uint16 Cla1funcsLoadStart;
    extern Uint16 Cla1funcsLoadEnd;
    extern Uint16 Cla1funcsRunStart;
    extern Uint16 Cla1funcsLoadSize;


    3. At the beginning of your code before you config your CLA make sure you use the memcpy to copy this section over from FLASH to RAM. When you have the emulator connected it automatically loads the code to the RUN memory.

    memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (Uint32)&RamfuncsLoadSize);

  • 0 in reply to Vishal_Coelho
    Prodigy 110 points

    Aah. I had all that in when I was using the ASM CLA code, but I didn't think it was needed for C, as the memcpy is commented out on all of the example files.Of course it did have me wondering how it ever loaded the code...

    I've always had the memcpy(&RamfuncsRunStart...   bit

    - I take it you mean memcpy(&Cla1funcsRunstart....).

    Thank you very much for setting me straight. I'll try it on my hardware when I get to work tomorrow.

     

  • 0 in reply to John Bennett
    Prodigy 110 points

    Yep that's fixed it. Thank you very, very, very much.

    Interestingly the board now doesn't need TDO and GPIO34 tied to 3V3 to boot. Wonder if it's just how they float. Need to get an understanding on what I can get away with as I've had a lot of boards built up that would need modding!! Anyway, up and running now, so thanks again.

     

    John

  • 0 in reply to John Bennett
    TI__Guru 57255 points

    John,

    TDO and GPIO34 have internal pull-ups that are enabled at reset. 

    External resistors are often recommended to pull these pins up for reliability in noisy systems, but are not necessary.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 110 points

    Thanks Brett, having some default pull-up is a relief, as I've got 30 PCBs that would require wire-modding.  I'll see how it goes when they test them in the field and get them modded at a later date if they require.

    A big thank you TI for this tech support system !.

     

    John