I am getting a hard fault - code goes into the FaultISR routine when connecting my board, running as a device, to a host (laptop). My board is using the LM3S5C51 part. I started with the CDC device example for the LM3S9B92 eval board (I have this code working). I then added this code to my project and compiled it for the LM3S5C51 with CCS. Everything builds ok and the board is up and running, but as soon as I connect to the host, the code ends up in the FaultISR while(1) loop. I have tried all of the peripheral and port pin enabling tricks but without success.
I did notice in the errata for the device that PB1 cannot be used for USB0VBUS. Question, how do I map the USB0VBUS to a different pin, and how should this pin be configured?
Section from errata sheet:
11.2 Special considerations for PB1Description:When using PB1 as a GPIO, special considerations are required due to issue “PB1 has permanentinternal pull-up resistance” on page 11.Workaround:The DEVMODOTG and DEVMOD bits in the USB General-Purpose Control and Status (USBGPCS)register can be used to configure the USB controller to operate only in Host mode or Device modeand allowing PB0 and PB1 to be used as GPIOs. If both the DEVMODOTG and DEVMOD bits are set,indicating Device mode, the USB VBUS signal must be monitored using a GPIO as an input todetect connect and disconnect. This monitoring must be done with a GPIO other than PB1, becausePB1 is not 5-V tolerant. Note that this erratum does not affect devices operating in OTG mode. TheUSB0VBUS signal operates as specified.In addition, if the USB functionality is not used on the device, in order to be able to use PB1 as aGPIO, the user application must enable the USB module in the RCGC2 register, set the DEVMODOTGbit, and then disable the USB module again. The restrictions detailed in issue “PB1 has permanentinternal pull-up resistance” on page 11 still apply.Silicon Revision Affected:A2Fixed:Not yet fixed.
Wanted to return & review this on-going saga. (feel the pain - both Joe & Rebecca) However - this new policy of, (pardonnez moi) "polluting each/every" TI response w/ hi-contrast ad is disturbing! Especially when TI response is short/sweet - large monitor "fills" with overly contrasted/over-kill ad. (i.e. 2-3 "ads" stack vertically down the screen - degrading both user's plea and TI response. ("ad" overwhelms text!)
Further - when reviewing on mobile device - the excess scrolling - forced by constant/chronic "ad repetition" - does not motivate one to, "rush to purchase!"
Know that Rebecca does not make such policy - cannot a less "visually over-whelming" ad be crammed down our throats - each/every TI response? This very much "failed experiment" should return to its poorly conceived - trash-heap origin - quickly! (someone had to say it...)
Rebecca,
I did some more debugging on the hard fault. Please see the attached pdf file. Let me know if you want me to test for anything else.
I did some more debugging on the hard fault. Looks like the insert file didn't work, so here it is again.
4657.HardFault.pdf
Hi Joe,
Thanks for going through with this fault analysis. I was able to re-compile your project (received from Rebecca) and reproduce a similar fault on an EK-LM3S9B92. The fault looks like it was caused by an invalid memory access, possibly due to prior stack or buffer overflow. After seeing this, I checked in the project settings, and noticed that the stack size was set to 256 bytes instead of the 1024 bytes used in the LM3S9B92 version of usb_dev_serial.
Increasing the stack size back to 1024 bytes eliminated the hard fault in my system. It might be worthwhile to try the same with your board to see if it makes a difference. If not, and you're still getting hard faults, feel free to post the NVIC_FAULT_STAT register contents again, and we can work together to figure out the actual root cause.
Regards,Christian
Christian and Rebecca,
Changing the stack size from 256 to 1024 fixed the problem, no more hard faults and I can verify the tx and rx of serial data. Hurray! I only changed the processor type and a couple of I/O pins when moving the example project to my board. So I tried a project that was using the evalbot and changed the project's processor from LM3S9B92 to my LM3S5C51 part. The stack size was set to 1024 originally, and with the processor change, the stack reset to 256. Maybe this is a default setting whenever you create a new project or change processors?
Thanks everyone for all of the help and I appreciate you sticking with it!
Best regards,
Joe