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.
Hello,
we've been facing the bus fault issues described in the "Tiva reset problem" thread (Errata SYSCTL#22), the reason and suggested fixes are understood and straight forward.
I'm just wondering if and why this issue had been never fixed within the TIRTOS TIVAC software package. Within a TIRTOS enabled project the system clock initialization is done over Boot_sysCtlClockFreqSetI() before main() is called. The function is part of the /packages/ti/catalog/arm/cortexm4/tiva/ce/lib/Boot.aem4f library and implemented within Boot_sysctl.c which is mostly copied from TivaWare's SysCtlClockFreqSet() function located in sysctrl.c. As the TivaWare version deployed over tirtos_tivac_2_16_01_14 package is still 2.1.1.71b it doesn't include the fix for SYSCTL#22 (fixed for versions > 2.1.3).
Replacing content of Boot_sysCtlClockFreqSetI function with SysCtlClockFreqSet content of TivaWare 2.2.0.295 fixed the issue for us. This is not very straight forward, as the /packages/ti/catalog/arm/cortexm4/tiva/ce/lib/Boot.aem4f library needs to get recompiled by hand...
Are there any updates planned for tirtos_tivac package or is this a "dead horse"?
Thanks for any feedback
Jens
Hello Jens,
Honestly I'm surprised this is the first time I am hearing this, I suppose the issue doesn't happen too commonly. Our TM4C team only picked up responsibility for TI-RTOS support recently (at least compared to the package being offered) and so the dated TivaWare being used still was not a choice we really made on our team. However since we do own the package now, the possibility to update it is a decision we can make and we are currently evaluating the best path for RTOS support (FreeRTOS also is on the table) so I cannot say today yes or no for a future update as it has not been determined by our team.
Regardless, I think we need to find some means to mitigate that particular issue so I'll raise it with our team and discuss ways we can at least get information like that more evident for customers to see early in development.
Best Regards,
Ralph Jacobi
Hello Ralph,
thanks for your fast response! Actually we've been detecting this issues while cyclically testing Ethernet based SW updates over our bootloader. The CPU got stuck after the update quiet often and we first thought this was only Ethernet related. We found out that our third party Ethernet driver was missing the fix suggested within ETH#02. After adapting the Ethernet driver the behavior was much better, but our board still got stuck from time to time (every couple of hundred reboots).
We're still in development phase and can live with the workaround for now. For series production we'd better not like to have to rebuild the TIRTOS library...
We've heard about the switch from TIRTOS support to FreeRTOS regarding another controller. When can we expect a decision on that? If required we prefer to prepare the migration while we're in development phase.
Thanks
Jens
Hello Jens,
I think by end of 1Q, but I can't guarantee that. Certainly before end of 2Q though. However, I will need to highlight that regardless of the path we choose - either an update to TI-RTOS or fully releasing collateral for using FreeRTOS with TM4C - it would take until end of year for development efforts to finish and to actually have a release that covers peripherals like Ethernet & USB.
Best Regards,
Ralph Jacobi
Hello Ralph,
thanks for this information.
is there a way to be directly in the loop in case of any news or is it better to put a reminder and refer to this thread?
Thanks
Jens
Hi Jens,
Unfortunately I don't have a way to really keep you in the loop on something like this, that's not really something that has been needed before. I would suggest you reach back out first week of April. I reasonably confident that we will have proper answers by then. Sorry that I can't give better news today but the last thing I want to do is promise X and then come back and say we are doing Y instead. This conversation definitely highlighted the urgency of which we need to make these decisions however so thanks for asking these questions.
Best Regards,
Ralph Jacobi