Issue with changing PAN1315 UART ports with Mindtree stack ...

Hi Miguel,

Thank you for your reply.

I've solved my issues and thought I would share to help others in the future.  One issue was my soldering.  I ended up getting a second board to work wired exactly like the example project but with wires wrapped to jumpers to validate the connections.  I then moved wire groups (RTS+CTS, RX+TX, SLOW_CLK, and NSHUTD) one by one.

One gotcha that I briefly mentioned before but didn't go into details is that the #define's for

BT_UART_CTS, BT_UART_RTS, BT_UART_TX, and BT_UART_RX all refer to the MSP430 side (not the HCI_RX [radio] side, for example).  The "BT" in the name threw me off but appears to just be a naming convention for all things bluetooth-related.

The true problem had to do with the CTS interrupt....

You cannot just change sdk_config.h pin information and expect everything to work.  There is an interrupt vector associated with CTS.  This can be found in aapl_bt_rf.c.  You need to modify this to point to the port you have CTS hooked up to, if you're not using PORT1.  Since this seems pretty integral to stack functionality, I'd recommend that we move a #define for it into sdk_config.h, much like the handling of "#define BT_UART_VECTOR USCI_A2_VECTOR."  If you get this wrong, the failure mechanism is that the radio turns on and device is visible, but pairing does not work.

I have not completely validated this, but I saw a couple of cases where Vdd appeared to be an issue also.  I assumed that I could run quite a bit lower than 3.3V (somewhere in the 2.5V to 3.0V range) as I thought the level shifters took everything to 1.8V.  There were a couple of instances where lower levels seemed problematic so I just ran my supply at 3.3V.  I haven't gone back to check to see exactly where the fail point is, however.

Getting schematics for the PAN1315ETU board would be very helpful though.  When you're debugging issues like this (unsure if it's HW or SW), it's very helpful to be able to have a view of the whole circuit, especially for probing.  Treating items like a black box is just one more thing that you can't validate the behavior of to eliminate it from your "possible problem" list...

Thanks again!

-Freddy

Hi Miguel,

This is a very good summary.  I also feel that the section on "adding new tasks" to FreeRTOS with the BT stack is very important for other developers (I lost a couple of days struggling with this).  I really appreciate you helping out on this.  I will try to post other info I discover that others may find helpful...

On a side note, I attended a TI course on low power MSP430 development that was given by many of the AEs in Dallas.  This course was very well done and very helpful.  Are there any courses planned on interfacing with the BT stack?  If not, could you perhaps recommend it to the management at TI?  It seems like this is of sufficient complexity to warrant something as such.  Being able to have discussions in person with TI experts is very valuable...

Thanks again!

-Freddy

Freddy:

Thank you very much for the suggestion to build a course about interfacing BT with MSP430.    We will definitely make this recommendation to management and see what we can do.

Thanks,

Dana Myers

Thanks Freddy. What is missing in Pages 14-19 in the Developer's Guide that would have ease your development? If you could give some examples, we can clarify those doubts and improve the documentation accordingly.

Regards,

Miguel

Hi Miguel,

In the version of the doc I have, here is what the adding tasks section says:

Creating additional tasks

New tasks can be created by calling the function xTaskCreate() of FreeRTOS. A corresponding entry needs
to be made in bt_os_thread_property[] structure. This structure is used to describe the task name,
priority and task stack size as the parameters. The order of task creation call in the code has to match
the entries in bt_os_thread_property[] structure. The stack size of the task will be allocated from
heap_memory variable of heap_bt.c. Hence OS_MAX_HEAP_MEMORY needs to be increased accordingly.
The type of stack size is defined as 16-bits. So, if the stack size of a task needs to be 256 bytes, the
configuration of the task stack size needs to be specified as 128 and the OS_MAX_HEAP_MEMORY will need
to be increased by 256 bytes.

I'm not sure if a code snippet could be  added to demonstrate where the user tasks should be added to the bt_os_thread_property array.  The FreeRTOS book does a very good job of showing code examples for task creation as an example (I suspect someone at TI or Mindtree probably has purchased this for your company):

http://www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html

The issue is that the order of the new tasks in the array doesn't seem to depend on when xTaskCreate is called.

The other note that I believe should be added is that not only does the task need to be added to bt_os_thread_property and OS_MAX_HEAP_MEMORY size increased, but configTOTAL_HEAP_SIZE in FreeRTOSConfig.h also needs to be increased.  Another option might be to change the source code such that there is a mathematical relationship between configTOTAL_HEAP_SIZE and OS_MAX_HEAP_MEMORY.

Please let me know if I was unclear or if I can help in any other way...

Thanks

-Freddy

Thanks Freddy. We will update the Developer's Guide accordingly.

Regards,

~Miguel

Hi Miguel,

I don't mean to resurrect a dead thread, but it seems that my colleagues and I have learned more about this issue.  It almost seems that there are 2 heap sections:

1) for normal FreeRTOS tasks

2) for bluetooth-related tasks

Pg. 13 of BlueMSP430 Developer's Guide v2.0:

EtherMind Bluetooth stack uses mainly two the Read and Write tasks. As part of the BlueMSP430 solution, FreeRTOS is used as the underlying OS. FreeRTOS is configured to be used in the pre-emptive scheduler mode. FreeRTOS provides three sample RAM allocation schemes as part of its source code. Scheme2(heap2.c) is used for task and semaphore management. In addition, Bluetooth buffer management is implemented as part of a custom scheme (heap_bt.c).

Pg. 19 of the MSP430BT5190+CC2560 Ethermind Bluetooth SDK Developer's Guide, 05-July-2010:

Creating additional tasks
New tasks can be created by calling the function xTaskCreate() of FreeRTOS. A corresponding entry needs
to be made in bt_os_thread_property[] structure. This structure is used to describe the task name,
priority and task stack size as the parameters. The order of task creation call in the code has to match
the entries in bt_os_thread_property[] structure. The stack size of the task will be allocated from
heap_memory variable of heap_bt.c. Hence OS_MAX_HEAP_MEMORY needs to be increased accordingly.

The type of stack size is defined as 16-bits. So, if the stack size of a task needs to be 256 bytes, the
configuration of the task stack size needs to be specified as 128 and the OS_MAX_HEAP_MEMORY will need
to be increased by 256 bytes.

The issue didn't come up until we added many tasks to the project.  It seems that tasks that do not use anything bluetooth specific should use the FreeRTOS heap method (configTOTAL_HEAP_SIZE) while bluetooth specific tasks (basically the ones that come with the project) should use the OS_MAX_MEMORY and BT_thread structure as mentioned above.

The issue that arises is that you run out of memory really fast (it seems you end up allocating space twice).  Doing as I mention in the previous paragraph seems to have created no issues when running the stack with FreeRTOS and our additional tasks.  I carefully stepped through the space allocation using FreeRTOS functions (all size allocations were as expected).  I also noticed that 2 heaps are created in the data section of memory.

Could you please clarify this functionality as the 2 documents don't seem to agree?

Thanks

-Freddy

Hi Freddy

I’m trying to add additional tasks as indicated in the user guide ,but unfortunately tasks that I added doesn’t work.

I modified in the BT_OS_THREAD_PROPERTY structure

 bt_os_thread_property[] = {

    {USER_TASK_NAME, USER_TASK_PRIORITY, USER_TASK_STACK_SIZE},

    {WRITE_TASK_NAME, WRITE_TASK_PRIORITY, WRITE_TASK_STACK_SIZE},

    {READ_TASK_NAME, READ_TASK_PRIORITY, READ_TASK_STACK_SIZE},

    {COMMANDE_TASK_NAME, COMMANDE_TASK_PRIORITY, COMMANDE_TASK_STACK_SIZE}

};

Also I modified  the size of “ OS_MAX_HEAP_MEMORY” to 1500.

The creation of the task when calling “vCreateCommande_Task()” is successful but the task is not executed by the scheduler and only the user task is executed.

Could you please help me to resolve this problem.

Thanks

Emna

Hi

I'm trying to add to the accelerometer project a cyclic task wich is blocked for a given time by the function "vTaskDelay" but the problem that when the "vTaskDelay" is called,

the task will never be executed and will be all the time in the delayed list.

How can I resolve this problem.

Hi Emna,

We have also had some issues with vTaskDelay with the beta 1.0 stack.  I'd like to get some clarification on your question to see if our problems align.

I'm assuming you do xTaskCreate, then the task is executed a first time.  That task calls vTaskDelay, which is when you see issues.  Is that correct?

This is essentially our method, and we have issues.  Unfortunately, I was not verbose enough with my notes in our bug tracking tool so I don't recall the exact behavior we saw.

We temporarily used __delay_cycles (the power hog method for the time being as our cases were pretty short and infrequent) and planned on going back to investigate this later.  I'm very interested to see if you're encountering issues also and what the proper solution is.

Thanks

-Freddy

Hi Freedy

Yes I'm working with the beta 1.0 stack. And I need a cyclic Task, I created it with xTaskCreate and it's executed only at first time and the call of vTaskDelay create the problem.

I can't use only use _delay_cycles because the routine of my task should be executed for example every 5 seconds.

Tahnks

Emna

Emna,

         We are looking at it and will provide some suggestions.

Thanks for your patience,

Hi Miguel,

Any word back on this?  After further analysis, this will be a problem for us to in the long run.

I'm not sure if this helps at all, but ...

We dug in a bit (don't have my notes in front of me), but I believe there is a function: vTickIncrement (might not be the exact name) that needs to be called from the timer interrupt handler.  I believe in the base FreeRTOS it's called in the vTickISR assembly code function.  I believe this code lives on in the port*.s43 file, although I believe this function is currently unused.

I believe there were 2 different timer settings that are used in the Mindtree stack though (0.25sec and 1sec according to the comments) in the TIMER1_A0 handler.  I realize that this would be problematic as vTaskDelay needs a steady base timer (of course, you could probably call vTickIncrement 4 times in the 1 second case to make up for it or roll your own 4x function that does xTickCount += 4 selectively).  I also realize that constantly waking up (1kHz is the base FreeRTOS frequency although it's configurable) when you should be in deep sleep mode is not ideal for power consumption either (so hooking another timer at the 1kHz default might not be a great solution).

It sounds like Emna's requirements are in the seconds range so a call in the current timer ISR might be ok there(?).  That resolution isn't great for us in general, but I don't think the energy trade-off for waking up more frequently would be worth it in our implementation (we'd probably roll our own solution where we temporarily hook a timer and use a semaphore to wake up a single time-based sleeping task).  We do have specific cases where even a 1 second resolution would be helpful though...

Does TI/Mindtree have any comments on the wake-up resolution vs. vTaskDelay?

Thanks

-Freddy