I ported the fix from WEC2013 back to WEC7 (the "fast-locking") on our custom BSP (we're using OMAP4, not really i.MX6) and by using your RTT driver/sdk/app I honestly do not see any major difference with the way that kernel behaves. If anything, I see even more time lost with the fix in place - it often breaks out quite soon, reporting the error. Sometimes when just using single core it runs for more than 1 hour without any issues (but just sometimes, not always), but with 2 cores it almost always breaks out instantly. I changed almost no code in RTT, except the sources/makefile adaptations. Due to the nature of time measurement used, I also had to include a high precision timer (MHz) in the OSDesign in order not to get data abort exceptions on divisions.
Could you possibly share any more details on what should we expect from the application once the system is free of this scheduler bug?
Fix on WEC7
I ported the fix from WEC2013 back to WEC7 (the "fast-locking") on our custom BSP (we're using OMAP4, not really i.MX6) and by using your RTT driver/sdk/app I honestly do not see any major difference with the way that kernel behaves. If anything, I see even more time lost with the fix in place - it often breaks out quite soon, reporting the error. Sometimes when just using single core it runs for more than 1 hour without any issues (but just sometimes, not always), but with 2 cores it almost always breaks out instantly. I changed almost no code in RTT, except the sources/makefile adaptations. Due to the nature of time measurement used, I also had to include a high precision timer (MHz) in the OSDesign in order not to get data abort exceptions on divisions.
Could you possibly share any more details on what should we expect from the application once the system is free of this scheduler bug?
Thanks!