| View previous topic :: View next topic |
| Author |
Message |
Oli
Guest
|
| CDC USB crashes upon printing numbers ( PIC24, PCD ) |
 Posted: Wed Sep 02, 2009 9:55 am |
 |
|
Hi All
I'm using PCD 4.098 on PIC24F256GB110 and have been using successfully the USB CDC drivers for the PIC24 series.
Unfortunately, I have made lots of changes to other parts of the program and until yesterday I had not checked the CDC functionality.
The problem is that whenever the PIC attempts to print an integer such as | Code: | | printf(usb_cdc_putc, ">%lu\r\n", adc_reading); |
, the USB connection is dropped. This does not happen with ALL integers though. It tends to happen more frequently with int32's.
I have not changed interrupts or changed any routines obviously affecting USB.
Does anybody have any suggestions as to the cause of this?
Many thanks in advance
Oli
Last edited by Oli on Thu Sep 03, 2009 3:44 am; edited 1 time in total |
|
 |
Gary Smithson
Joined: 13 Feb 2004
Posts: 22
|
|
| Posted: Wed Sep 02, 2009 11:15 am |
|
|
I am having the same problem with 4.098 PCD, HID USB, printf and floats. In my case the PIC is resetting. Yours probably is to. I have reported it to CCS and they can't recreate the problem (they used RS232 instead of USB for their putc). I have a hunch it has something to do with code size/complexity.
My problem changes as I add code in other areas. Some days the PIC resets only when I print floats. Other days it will print int but skips some of the digits.
I'll try to remember to post back if a solution is found.
Gary |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Sep 02, 2009 1:51 pm |
|
|
| Quote: |
The problem is that whenever the PIC attempts to print an integer such as:
printf(usb_cdc_putc, ">%lu\r\n", adc_reading);
the USB connection is dropped. This does not happen with ALL integers though. It tends to happen more frequently with int32's. |
Try a work-around. Instead of printf, use sprintf() to generate the
ASCII string and put it in an array. Then use a for() loop to call the
usb_cdc_putc() routine, once for each byte. Test each byte before
transmitting it, to see if it's the string terminator byte of 0x00. If so,
then exit the loop. |
|
|
Gary Smithson
Joined: 13 Feb 2004
Posts: 22
|
|
| Posted: Wed Sep 02, 2009 11:08 pm |
|
|
Just a real quick update. 4.099 did not fix the problem.
I tried the following code and didn't even bother printing out the result string. The PIC reset.
| Code: |
char temp_str[50];
sprintf (temp_str, "%4.2g", float_value);
|
I have not had time to do further testing. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Sep 03, 2009 12:07 am |
|
|
You may want to check, what exactly causes the crash respectively USB disconnect. Debugger action is most likely required.
I once experienced a strange problem with PIC18 CDC code, where global interrupts had been disabled inadvertently somewhere in the CDC driver code. I didn't clarify the exact reason but could handle it by reenabling interrupts in the main loop.
Another popular crash mechanism with PIC24 is the address error trap. It can be triggerred by coding errors of yours as well as possible PCD coding bugs. Address errors can be handled and visualized by a small handler,see: http://www.ccsinfo.com/forum/viewtopic.php?t=36479 |
|
|
Oli
Guest
|
|
| Posted: Thu Sep 03, 2009 3:44 am |
|
|
Gary, it's reassuring that it's not just me experiencing that problem - The symptoms you describe are exactly the same as mine. I have PM'd you.
I have a explorer16 board with USB module to hand and have successfully worked with CCS to identify a problem previously (another CDC issue, fixed in 4.093) - they have this exact board so we can both work from the same code base. I will try and produce an isolated example to submit to them as soon as possible. That way they will definately be able to reproduce the problem.
PCM, FvM, Thanks for your suggestions - I will investigate this later on today.
4.099 has not made a difference for me either... |
|
|
Gary Smithson
Joined: 13 Feb 2004
Posts: 22
|
|
| Posted: Thu Sep 03, 2009 12:51 pm |
|
|
Oli, As you might expect I am also using the Explorer 16 with USB PICtail. If this problem lingers I will also share my source code with CCS but since I am a Microchip Design Partner and don't really own the code, I hesitate. I can see you're doing all the right things to get the issue resolved. Luckily for me, my printf is only for debug messages and not critical to the application.
FvM, Thank you for the link to that very useful error trap code. I feel lazy for not already having something like this in place.
Gary |
|
|
Oli
Guest
|
| possible solution! |
| Posted: Fri Sep 11, 2009 3:58 am |
|
|
Hi Gary
Try adding #build (stack=256) after the fuses. It seems to have alleviated the problem in the one quick test I have done - fingers crossed!
Let me know how you get on! Thanks for everyones replies.
Oli |
|
|
Gary Smithson
Joined: 13 Feb 2004
Posts: 22
|
|
| Posted: Fri Sep 11, 2009 12:54 pm |
|
|
Oli,
That did it. Good work.
The documentation says the default stack size is 256 but CCS must not actually be using that value.
Thanks for posting back.
Gary |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Fri Sep 11, 2009 5:39 pm |
|
|
| The best way to identify stack problems and locate the code line that triggers it would be a stack error trap routine. Unfortunately, an error trap for stack overflows with #INT_STACKERR doesn't work, because the PCD ISR entry code is using the stack itself. Pushing further data on the stack in the stack error trap ISR causes an immediate trap conflict reset. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Sat Sep 12, 2009 3:58 am |
|
|
A short update on stack error traps with PCD:
I found, that in contrast to my previous post, they can work. But the default PCD stack configuration must be modified. Normally, PCD places the stack at top of data address space, with SPLIM set to the highest available address. In this case, the error trap ISR can't be executed, because there's no stack room for return address and processor status. To allow execution of the #INT_STACKERR function, free data space must exist above SPLIM, at least 64 bytes.
| Code: | #build(stack = 128) // The default PCD setting
#build(stack = 0x4700:0x477e) // 128 bytes of stack and 128 bytes extra room (with 24FJGA/GB1xx) |
Then you can e.g. record the code address, where the stack error occurred. To allow further code execution without immediately causing a new stack error trap on the next push action after returning from the error trap, SPLIM can be increased in the error trap function.
Of course, a processor reset or at least a stack reinitialization at the main() level must follow, but you are possibly able to display the error address without using the debugger.
A restriction is however, that the error trap most likely occurs at the next interrupt (either before entering the ISR or during it's execution) rather than at the faulty code location (if any), that originated the stack overflow. But at least, you get a clear information, that a stack error occurred. And hopefully, you can narrow down the problem. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Mon Sep 14, 2009 12:25 am |
|
|
Another update on the stack error issue.
It turned out, that an application with this stack requirement report in the PCD list file
| Quote: | | Stack: 29 worst case (21 in main + 8 for interrupts) |
actually required 71 words respectively 142 Bytes of stack up to the interrupt level, without considering trap ISRs (this must not be necessarily the worst case requirement). Either, the above report has a different meaning than what it seems to be to common sense, or it's simply incorrect. |
|
|
Rogier
Joined: 25 Feb 2012
Posts: 12
Location: NL
|
| Re: possible solution! For me too |
| Posted: Wed Jan 19, 2022 1:09 am |
|
|
| Oli wrote: | Hi Gary
Try adding #build (stack=256) after the fuses. It seems to have alleviated the problem in the one quick test I have done - fingers crossed!
Let me know how you get on! Thanks for everyones replies.
Oli |
I got a reset (after some USB cdc sendings) once in a while. Reset cause was a trap conflict. This helped me too! PIC24FJ128GB202 (CCS 5.070) |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
