• State Resolved
  • Locked Locked
  • Replies 30 replies
  • Subscribers 81 subscribers
  • Views 3566 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.

[Concerto] Problem with Lab5

Disona
Genius 3050 points
Other Parts Discussed in Thread: CONTROLSUITE

Hello everyone!

Recently I have asked a question about failure with booting Concerto (F28M35H52C1) in Standalone Mode using flash. The last question in that thread - http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/279135/974871.aspx#974871 .

I was examining Lab 5 from Concerto workshop (unchanged, from the "Solutions" folder).

But today I had some progress exploring reasons of such a strange behavior. It's in the usDelay ASM function, which is used in InitAdc1() - this call caused reboot of both CPUs (I can tell that by LEDs). Let me describe the strangest thing:

1. Load programs in FLASH memorys (memories?).
2. Check it in Debug mode - running.
3. Disconnect target (without terminating Debug Session), program keeps running. Power off the MCU.
4. Power on - not running.
5. And then connect back to the MCU without reloading program and launching - running.

I can't understand this, this may be CCS error. So the only thing I could do - was to comment the line DELAY_US(ADC_usDELAY) in InitAdc1().
After that the first part of code works properly. But i got a new problem, and now I have no idea how to solve it.

The ARM core falls(haha) to the Fault_ISR() after executing the IPCCtoMFlagAcknowledge(IPC_CTOMIPCACK_IPC1) 

Voltage_M3[2]= AdcValue; // read and store result from CtoM – Ram

in Lab5_M3.c. The C28 continues running. And it acts just like described above - the program is working properly only with debugger connected to the MCU.
I am now reading TRM: IPC, looking for answer, but can't find anything. I've checked forum, and found no such problem.

Upd1 [25 Jul] - problem is in reading from CtoM RAM.

Also, please look at this post of this thread: http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/279813/976825.aspx#976825
Please, help. 

  • 0
    Guru 20525 points

    Hello Disona!

    I suspect your Control Card is powered by USB-device of PC.

    Regards,

    Igor 

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hello, Igor!

    Igor Gorbachev said:

    I suspect your Control Card is power by USB-device of PC.

    Yes and no =). I tried both ways. It was in the post, but suddenly got erased (don't know why). I'm using dockingStation and Developers kit (or experimenters) - that's a nice big darkblue circuit board with inverter and stuff. With this one there's no need to use USB power cable, only JTAG. 
    Also, it was tested on two different controlCARDs.
    System: Windows 7/8, CCS v5.4 

    But by your words I guess, the problem can be caused by using USB power cable? Could you tell me please, where can I read about it? 

  • 0 in reply to Disona
    Guru 20525 points

    Hi!

    Please specify the following steps:

    4. Power on - not running.
    5. And then connect back to the MCU without reloading program and launching - running

    (power is ON, you connect MCU to USB-port of PC and then program starts itself? Is not it? Or you do something for launching?)

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi,

    well, yes, i do =) "Connecting" means pressing buttons "connect target" on M3 and C28. "Launching" means pressing button "Run". But I don't Reload Program.

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    Well...Thus your device starts only at debug mode and one can't start at standalone mode. It seems this issue of boot from flash...

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Thanks for your replies, Igor.

    Sorry for the bothering, but i discovered new... hm... bugs (or, if you prefer, features).

    So. The wierdest thing of all. I always thought, that it doesn't matter where the MCU is located, is it day or night, are you in good mood or else... well I thought, that loaded programm will run absolutely identically every time you start it. Now i know, that it's not true. It's very hard to explain, cuz my english is not that good, but i'll try to.

    First of all, let me exlain method i'm using to recognise states of M3 and C28 (especially C28) CPUs by looking at LED.

    ledPause = 0;                          
    GpioG1DataRegs.GPCDAT.bit.GPIO70 = 0;   // This turns C28 LED ON
    while (ledPause++ <10000000);           // It's a long pause for me

    So I can insert this code in any part of the program to see, if the command, following this script, will reset CPU (or else). For example, if I see, that LED turned on, and then it leaves in ON state, that means that the program is running right (if there are no more commands affecting LED's state, of course).
    I've discovered some ways of running program in STANDALONE mode (states of M3 and C28 CPUs are recognized by looking at respective LEDs).  Here they are:

    Scenario I:
    1. M3 starts, then it boots C28.
    2. M3 and C28 restart (WHY???). M3 starts again and boots C28 again. Both CPUs are running.
    3. C28 enters an ISR (EOC of ADC) and it ruins M3. (C28 keeps running)

     Scenario II:
    1. M3 starts, then it boots C28.
    2. Both CPUs are running.
    3. C28 enters an ISR (EOC of ADC) and it ruins M3. (C28 keeps running)

     Scenario III:
    1. M3 starts, then it boots C28.
    2. M3 and C28 restart (WHY???). M3 starts again and boots C28 again. Both CPUs are running.
    3. Everything is OK, just as planned.

     Scenario IV:
    1. M3 starts, then it boots C28.
    2. Both CPUs are running.
    3. Everything is OK, just as planned.

    I thought, that problem is in RAM. The big blue cirquit board has heavy capacitors, and after turning the board off LEDs resume lighting for about 4 seconds. So I supposed, that different scenarios are achieved by different pauses between POWER ONs and POWER OFFs. But no, I can turn it off, then wait for 10 seconds and turn it on, and the MCU is running. I can wait for 1 second. I can hold the MCU running for different periods of time between power ons and offs.

    Result is unpredictable every time.

    To be honest, I suppose that the problem is with the cores (hardware). I'm going to test it once again on another controlCARD.
    The projects, which caused this, are attached. 

    Lab5.zip
  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    I think there is no problem with cores, but there is problem with using cores. At first I would recommend you pay attention at Blynki example project from ti\controlSUITE\device_support\f28m35x\v201\ and to study carefully all variants: Control (28x core), Master (M3 core) & Dual (28x + M3 cores).

    Regards,

    Igor 

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi Igor!

    Thank you for the advice. I went through these examples, and they are working properly. All the initializatons, performed in the examples, are presented in Lab3 too. But the examples are using neither ADC nor IPC (these modules caused problems).

    Our other projects withot IPC and ADC are working fine too.

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    Fine! And did you try these projects at standalone mode of MCU (the boot from flash without debugger)?

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi, Igor.

    Yes, of course I've tried. =)

    Disona said:

    they are working properly

    More than that: i've tried to run it even without putting TRST in 0, and it works. And even with the debugger connected it works. Don't know...

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    i.e. you want to say that above "strange behavior" did not take place when you tried these projects. Do I understand you?...Thus we have returned to the title of your post  "Problem with Lab5" (and only with Lab5 exactly). Well...The progress is not big. But at least the problem has become more localized. And what about your Lab5.zip? Is this source code without  some your changes or not? It is desirable to have "clean" the source code.

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi, Igor.

    Yes, that's right. I'm almost sure, the problem is in IPC. I attached clean source code of Lab5.

    Lab5.zip
  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    Ok. Is there any readme about this project (or what this project had to do?... in a nutshell).

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi,

    yes, attached file contains description of all labs, this one is Lab5.
    In few words: C28 gets some results from ADC, then stores it into the shared CtoM RAM, send IPC flag to M3 to tell it "Result is ready", M3 get's that flag, copies results from shared memory to it's own memory, and sends Acknowledge IPC command to C28.

    In my case, it stops working right after IPCAcknowledge command.
    Thanks for help, Igor. 

    F28M35x_Workshop_2-0.pdf
  • 0 in reply to Disona
    Guru 20525 points

    Hi!

    Ok...it is too early to say thanks. Everything is not clear yet...

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    You're the only one who does help with this case, so... =)

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    Well, we'll hope that the Holy Inquisition (TI employees) will connect to this thread at near time also :-)

    Regards,

    Igor

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    Before we go further let's do some resume. If I'm wrong then corret me please. So:

    1 All the Blink example projects from controlSUITE (Control, Master, Dual) work in bouth modes (debug & standalone).

    2 Lab3 works in bouth modes.

    3 Lab5 works (let's specify the correct option once again):

            3.1 in bouth modes; 

            3.2 only in debug mode;

            3.3 only in debug mode after you have modified some code in Lab5, but before it worked in bouth mode.

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hello, Igor!

    Well, by paragraphs:
    1. Yes, Blinkies are running in both modes (even mentioning in Dual example, that it probably won't run in the debug mode).
    2. Yes, Lab3 is working properly in both modes.
    3. -> 3.2 Lab5 only works in debug mode.

    And also, there (in Lab5) are two problem points. The first one was in the InitAdc1() function. I've changed it a bit - commented the last command:

    void InitAdc1(void)
    {
    extern void DSP28x_usDelay(Uint32 Count);

    // To powerup the ADC1 the ADC1ENCLK bit should be set first to enable
    // clocks, followed by powering up the bandgap, reference circuitry, and
    // ADC1 core.
    // Before the first conversion is performed a 5ms delay must be observed
    // after power up to give all analog circuits time to power up and settle

    // Please note that for the delay function below to operate correctly the
    // CPU_RATE define statement in the F28M35xA_Examples.h file must
    // contain the correct CPU clock period in nanoseconds.
    EALLOW;
    Adc1Regs.ADCCTL1.bit.ADCBGPWD = 1; // Power ADC1 BG
    Adc1Regs.ADCCTL1.bit.ADCREFPWD = 1; // Power reference
    Adc1Regs.ADCCTL1.bit.ADCPWDN = 1; // Power ADC1
    Adc1Regs.ADCCTL1.bit.ADCENABLE = 1; // Enable ADC1
    Adc1Regs.ADCCTL1.bit.ADCREFSEL = 0; // Select interal BG
    EDIS;

    DELAY_US(ADC_usDELAY); // Delay before converting ADC1 channels
    }

    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |
    |

    |
    |
    |
    |
    | 

    void InitAdc1(void)
    {
    extern void DSP28x_usDelay(Uint32 Count);

    // To powerup the ADC1 the ADC1ENCLK bit should be set first to enable
    // clocks, followed by powering up the bandgap, reference circuitry, and
    // ADC1 core.
    // Before the first conversion is performed a 5ms delay must be observed
    // after power up to give all analog circuits time to power up and settle

    // Please note that for the delay function below to operate correctly the
    // CPU_RATE define statement in the F28M35xA_Examples.h file must
    // contain the correct CPU clock period in nanoseconds.
    EALLOW;
    Adc1Regs.ADCCTL1.bit.ADCBGPWD = 1; // Power ADC1 BG
    Adc1Regs.ADCCTL1.bit.ADCREFPWD = 1; // Power reference
    Adc1Regs.ADCCTL1.bit.ADCPWDN = 1; // Power ADC1
    Adc1Regs.ADCCTL1.bit.ADCENABLE = 1; // Enable ADC1
    Adc1Regs.ADCCTL1.bit.ADCREFSEL = 0; // Select interal BG
    EDIS;

    // DELAY_US(ADC_usDELAY); // Delay before converting ADC1 channels
    }

    Next problem is in M3's command IPCCtoMFlagAcknowledge(IPC_CTOMIPCACK_IPC1). If i comment this - Lab5 is working properly (with Delay_US commented too).

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona! Thanks.

    1 It's all right with it: the Dual variant is not intended for debug mode.

    2 Ok.

    3 We will think about it tomorrow. I'm tired and I have my birthday today :-)

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Wow, Happy Birthday and may all your dreams come true =)
    Then, I guess, we'll continue after tomorrow ;) 

  • 0 in reply to Disona
    Guru 20525 points

    Many thanks!

    Bye!

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi!
    We discovered, that I was wrong - problem is not in IPCAcknowledge command. The problem is in reading from shared CtoM memory (M3 fails after reading a value from this memory). In standalone mode, of course. In the debug mode it's all right.

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    If the case will go this way then my help will not be needed. Let's me know if new information will be. And what about DELAY_US from "void InitAdc1(void)"? Does this macro hinder really? Or its effect is secondary? 

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hello Igor!
    Well, DELAY_US  is commented out. If I leave this command uncommented, then no projects work at all.

    By the way, another project after commenting US_DELAY runs perfectly, although project is large enough and includes lots of interrupts, ADC, EPWMs, Shared RAM Memory.

    P.S.: there is an idea, that problem is in NMI Watchdog, we'll check this. 

  • 0 in reply to Disona
    Guru 20525 points

    Hi!

    Try to transfer a parameter explicitly: US_DELAY(1000L) instead DELAY_US(ADC_usDELAY) and also you can refer to http://e2e.ti.com/support/microcontrollers/c2000/f/171/p/276146/963565.aspx#963565.

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hi!
    I think I'm close to the solution. I guess the problem is in RAM initialization. in debug mode it's performed by GEL scripts. In standalone I should use some functions, but I can't find them.
    Do you know these functions? Where can I get them? Santosh (from TI) sent the other guy to read paragraph 5.1.7 of Concerto TRM. But there is no such paragraph =)
    Could you help me with this please? 

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    I didn't find 5.1.7 into TRM 4405.TI_F28M35x_TRM.pdf. This paragraph is absent. But I think 5.11.9, 6.5.4, 6.5.9, 6.6.2 will be useful at your issue. About some special initialize functions I do not have any information so far.

    Regards,

    Igor

  • 0 in reply to Igor Gorbachev
    Genius 3050 points

    Hello, Igor!
    Finally, it's done! =)
    The problem was caused by uninitialized CtoM RAM memory, that caused Parity (I guess) errors. Indeed, GEL scripts, that are used in the debug mode, initialized all the memory automaticly. In standalone mode I had to do this manually, by writing "1" in RAMINIT_CTOMMSGRAM field.

    Thanks for help! 

  • 0 in reply to Disona
    Guru 20525 points

    Hi Disona!

    I'm glad if my help was useful in fact.

    Regards,

    Igor