TivaWare DriverLib Bugs

Hello Andy,

The ROM functions are only a link to the ROM Mapping table. Building assert directive would increase the size of ROM being used. However to the specific issue you have mentioned, if the define for the GPIO is there in the part, then it would not fail in non-ROM locations.

Regards

Amit

I understand and agree, but the problem is that it does in fact fail using the non-ROM function.

According to the user TM4C129XNCZAD user guide, the GPIO_PR1_LCDFP define is for a valid signal.  In the driverlib pin_map.h, the GPIO_PR1_LCDFP define is defined for the TM4C129XNCZAD part.  The LCDFP signal is used for any project that uses the PinoutSet() function from pinout.c for that development kit.  There is nothing that is telling me that the assert should fail.

Steps to reproduce my example problem:

Change line 177 of SW-TM4C-2.1.0.12573\examples\boards\dk-tm4c129x\drivers\pinout.c to use the non-ROM function.
Add an infinite loop in the __error__() function in SW-TM4C-2.1.0.12573\examples\boards\dk-tm4c129x\uart_echo\uart_echo.c, and set a breakpoint there.
Add the DEBUG define in the uart_echo predefined symbol list.
Run the modified uart_echo project on the board and observe that the breakpoint gets hit.

My general concern is that there are more than just this one assert that may fail.  It is clear that the driverlib is not tested sufficiently to verify the non-ROM functions do not assert for all valid parts and pins defined in the driverlib.  In fact, based on the logic in the assert in the GPIOPinConfigure() function, all TM4C129XNCZAD pin defines for Port R and higher will fail the first assert.

Hello Andy

OK. I will try the same and update. However do send in your CCS project as well (if you can share the same on the forum) so that I have a reference to compare to.

Regards

Amit

Hello Andy,

I did the steps as you mentioned (following is the line I changed)

    GPIOPinConfigure(GPIO_PR1_LCDFP);

And it works w/o any issue. Just to double confirm, I have added the CCS Project.

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/908/6558.uart_5F00_echo.7z

Regards

Amit

Amit,

I have attached my uart_echo project. http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/908/2112.uart_5F00_echo.7z

Included are screenshots showing breakpoints for each function call leading to the assert.  I have found it confusing importing projects into my workspace from the examples since there are referenced files.  I frequently found myself modifying the wrong copy of the file...  My project should have all necessary files included and not depend on any previous TivaWare installation.  I suspect you may have changed file that was not actually referenced by your project.  Please see if you can reproduce my screenshots using either your or my project.

Thanks,

Andy

GPIO_PR1_LCDFP is defined as 0x000F040F, and (0x000F040F >> 16) equals 15, so it seems it shouldn't pass an assert of < 15.

Hello Jon

I agree with you. Can you use the example project to replicate it. May be I have got something overlooked in my setup.

Regards

Amit

Hi Amit,

I was able to build and debug your project, and modified PinoutSet() (from pinout.c in examples/boards/dk-tm4c129x/drivers) so that it would try GPIOPinConfigure(GPIO_PR1_LCDFP) first.  Initially I was not able to step inside of that function, and was greeted by a "source not found" window.  Perhaps you are using a precompiled driverlib?  I went and explicitly copied gpio.c into the project source directory, and then I was able to step in and test the assert.  Similar to Andy's test, the assert failed.  See the attached zip of screenshots.

Jon

Hello Jon,

I also thought about the same and realized that I have the precompiled driverlib version. Will double check and confirm.

Regards

Amit

Hello Jon, Andy,

I confirm the issue and have filed an internal bug to correct the driverlib,

Regards

Amit