BQ79616EVM-021: RTI_TIMEOUT allway == 0

Hi Harry,

Are you seeing the device wake up? Are you able to run the code in a debugger and observe what it is stepping through? I'd like to confirm that RTI_TIMEOUT is properly stuck. 

Best Regards,

Anthony Pham

Hallo Anthony,

yes can debug and go step by step through the code.

   1. The main function calls Wake79616 function
   2. The Wake79616 function calls delayus(uint16 us)
   3.  Inside the delayus function is the loop while(RTI_TIMEOUT==0) in which the program is hanging.

-----------------------------------------

I think the problem is in the configuration of the RTI in HALCoGen.

I have replaced the marked value from 0.001 to 1.000 and now the program is runing. 

Could you please check and confirm that the value 1.000 is the right value.

Thank you in advance

Harry 

Hi Harry,

Let me take a look into this. Will update as soon as I can. 

Best Regards,

Anthony Pham

Hi Harry,

I'm reassigning this to the group that supports the TMS570LS12 LaunchPad. If there are any questions regarding BQ79616, feel free to resubmit a new forum question. 

Best Regards,

Anthony Pham

Hi Anthony,

I am unable to download your code,

But make sure the following things:

1. Make sure to call the following RTI functions:

     rtiInit();

    rtiEnableNotification(rtiNOTIFICATION_COMPARE0);

    rtiStartCounter(rtiCOUNTER_BLOCK0);

2. Make sure to enable the IRQ interrupt in the code: 

    _enable_IRQ();

3. Make sure to enable RTI Compare 0 interrupt in HALCoGen

4. For more details you can refer rtiBlinky example in HALCoGen:

You can access this example as below:

In this example you can find step by step procedure and code for RTI blinky exampl.

--
Thanks & regards,
Jagadish.

Hello Jagadish,

I have added a project so you can see all settings.

1. It is basically a example project from TI. I have chacked the Points 1 to 4 what you have mantioned in your message. All is OK.

    So I think my asumption and correction from 0,001 to 1.000 was correct.

2. Could you please look in the main function.

    If I set #define OBJECT_COUNT to a value bigger then 40 then I have an unpredictable behavier. In the best case the program don't run but some times
    the values of obj.V are random values. I think this is a matter of heap size. Could you plese help me to make right settings to solve this problem.

Thank you in advance

Harry

_Test.zip

Hi Harry,

Harry Steinhauer said:

1. It is basically a example project from TI. I have chacked the Points 1 to 4 what you have mantioned in your message. All is OK.

    So I think my asumption and correction from 0,001 to 1.000 was correct.

I don't think 0.001 was wrong. If we configure 0.001 means we are generating 1uS interrupt. I think that was correct only.

I forgot mention the below thing, make sure to SET the RTI_TIMEOUT to 1 in the rtiNotification function as below:

Harry Steinhauer said:

If I set #define OBJECT_COUNT to a value bigger then 40 then I have an unpredictable behavier. In the best case the program don't run but some times

Your memory allocation seems to wrong for me. Please try to do as below:

--
Thanks & regards,
Jagadish.

Hallo Jagadish,

1. I have shanged the 1.000 back to 0.001 and now it works. Magic. this is behind my imagination. :-)
    This point in done. Thank you! 

2. You're right, I was about to do a little project for you so you can see the problem and I made typos.

    I have correct the typos and now I have following outputs

If OBJECT_COUNT = 20 then

obj[5].V[2] = 3.060000,
The End of program

this is OK!

but if OBJECT_COUNT = 30 then
no output at all

If OBJECT_COUNT = 40 then

obj[8].V[7] = 0.001953,
obj[10].V[12] = 0.001953,
obj[13].V[4] = 0.001953,
obj[17].V[12] = 0.000488,
obj[20].V[6] = 0.001953,
The End of program

It shoud be allways 

obj[5].V[2] = 3.060000,

Because 

for(int i = 0; i<OBJECT_COUNT; i++)
{
memset(&obj[i].V, 0, 16 * sizeof(float));
}

sets all values to 0

and     obj[5].V[2] = 3.06; sets 3.V of the 6. object to 3.06.

And I print just V > 0.0001

Please find attached the corrrected version

Thank you in advance
Harry

6710._Test.zip

i think it is some thimg with HALCoGen.

or compiler

Hallo Jagadish,

it seems like the call

obj = (Object*)malloc(OBJECT_COUNT * sizeof(Object));

delivers a valid pointer only if OBJECT_COUNT <= 20 in other cases it returns NULL Pointer.

That is the problem

Best regards
Harry

Hi Harry,

Harry Steinhauer said:

If OBJECT_COUNT = 20 then

obj[5].V[2] = 3.060000,
The End of program

this is OK!

but if OBJECT_COUNT = 30 then
no output at all

I understood the root cause for the issue.

The C/C++ compiler uses an uninitialized section .sysmem for the C run-time memory pool used by malloc(). The size of this memory pool is set at link time by using the --heap_size option. The linker creates the .sysmem section only if there is a .sysmem section in an input file.

If --help_size is not used in linker cmd file or not included in CCS like options, 0x800 will be used as default for .sysmem. 

You can find the allocated memory for system in the map file like as shown in figure.

0x800 means 2048 bytes and in our case one object data size is equal to the (16*size of float) that is equal to the 64bytes. That means the maximum ideal number of objects that can be created will be 2048/64 and which is 32. This is ideal but entire .system section will not be ment for heap right so it could be under 30 as well.

The solution for this problem is to increase the heap size:

Go to the project properties and increase the below highlighted value:

I am increasing this value to 0x1000:

Once you change the value do clean build of project to get this setting affect:

Once you did the clean build you can verify .system section memory configured 0x1000 in map file as shown below:

Previously even 30 objects doesn't work for me but now i configured 35 objects and verified the result:

Now it is worked without any issue.

--
Thanks & regards,
Jagadish.

Hallo Jagadish,

this works! Great!

My MCU has 1280KB.

The out file is ~ 400KB

Does it mean I have ~ 800KB for stack and heap memory?

Or are there some other points to concider?

Best regars
Harry