while running target board error appears as bad packet type 001 sub type 015 , and immediately stopped
Does this happen when you run unmodified versions of the sample programs provided with Dynamic C? If samples work but your code does not, there’s probably a bug in your code that crashes the program.
Have you updated to the latest version of Dynamic C for the given product (Dynamic C 9.62 for Rabbit 2000 and 3000; Dynamic C 10.72A for Rabbit 4000, 5000, and 6000)?
Which product are you seeing this with?
I’m having this same issue, but I’ve lint’d the code and I can’t find a problem. I don’t think anything is getting walked on.
This is a Rabbit 37xx and DC 9.62 with all updates applied.
What I find interesting is that the dialog reporting the packet error and the error text, is nowhere to be found in any of the libraries. So, this is something within DC 9.62 and it must have to do with RST28 debugging.
I think the packet being reported is communication between the target and the DC application, not my application itself because that does not fall over. It continues to operate, albeit at a slower speed. Selecting F4 halts it.
Someone at Digi has the source for DC 9.62. If they could confirm that this is coming from DC itself, and where/why, we may be able to resolve this. Perhaps there is some sort of checksum error taking place over the USB line to the programming interface?
Can someone please help? Thanks!
You might want to create a new question for your issue to get additional attention to it. Can you answer the questions I asked of the original poster? Do you get that error when running standard samples? How often does it happen? It’s definitely an error on the debugger side, related to debug communications. Can you post a screenshot of the error, or the exact wording? I think that subtype is in hex (0x15), so it’s related to printing to stdout. If I had to guess, I’d say that you’re overflowing the printf() buffer used for debug communications, and that causes the program to crash or become unstable. If STDIO_ENABLE_LONG_STRINGS isn’t defined, you can only print 127 bytes at a time.
I think you’ve got it. I use printf’s all throughout the code because I need to see what’s happening in as close to realtime as possible. It is very possible that if the printf buffer is only 127 bytes, I’m overflowing it. Many message buffers are set to 255, and I guess it only takes 1 byte @ 128 to overflow. I am going to enable the long strings and see what that does. Since you know about this, can you tell me what happens to stdio output once the programming cable is off the rabbit? Is it discarded? Obviously it takes overhead and in the final release I think all output should be removed. Thanks Tom!!!
If you’re not connected to the debugger, it’s usually ignored, but you can enable compile-time macros to have it go out the serial port at some specified baud rate. Take a look at Samples/STDIO_SERIAL.C.
Bumping my comment to another answer out into its own answer for others who might run into this.
Type 001 is “debug” and I think that subtype is printed in hex (0x15), so it’s related to printing to stdout. If I had to guess, I’d say that you’re overflowing the printf() buffer used for debug communications, and that causes the program to crash or become unstable. If STDIO_ENABLE_LONG_STRINGS isn’t defined, you can only print 127 bytes at a time.
I will do that. I am pretty sure this is my problem. I have several tasks and none considers the other with regard to printf.
“As of Dynamic C 8.50, printf can print more than 127 bytes at a time if the
STDIO_ENABLE_LONG_STRINGS macro is defined. If this macro is defined in a
multi-tasking application and more than one task is utilizing printf and at
least one task is printing strings longer than 127 bytes, the application will
need to ensure serialization of access to printf (via a semaphore or something
similar) so that printf output from different tasks is not interleaved in the
stdio window.”
I’d like to know where to find the list of these cryptic error codes.
I’m getting Bad Packet - type: 040, subtype: 01c
Where do I look to decipher this code?
I’m an engineer doing some maintenance on a project which incorporated a Rabbit (not my choice), and I’m finding the debugger to be rather difficult to decipher as compared to microchip’s and Atmel’s.
On Dynamic C 9, I found the types in Lib/BIOSLIB/tc_defs.lib, but that doesn’t include a type 0x40. The subtypes for type 0x01 (DEBUG) appear in Lib/BIOSLIB/DKCORE.LIB. If it’s somehow a corrupted DEBUG packet, subtype 0x1c is TC_DEBUG_WRITESTACKSIZE.
Because the debugger is hosted on the target and runs over a serial UART (as opposed to a JTAG interface), crashing programs will often result in weird packet errors.
I ran code that I had previously completely debugged in Wine on Ubuntu, then tested for weeks.
On my Win 10 machine at work, these weird errors occurred with another change to the code, so I fugured I must have made some error.
So I reverted. But now, all these weird errors again. Looked at the project options, made sure I had the same selections in place.
I changed to Win 7 compatibility and stopped this service:
windows ip phone over usb (IpOverUsbSvc)
Suddenly the previously functioning code worked in debug mode.
I restarted the machine and the issues came back. Then I stopped IpOverUsbSvc again and the debugger worked with the reverted code, again. Then I restarted IpOverUsbSvc and while the debugger ran okay, I noticed that the flash loader had to restart in the middle.
So, I’m thinking there’s a usb aspect here, but I’m not 100% sure. It could be difficult to be sure, if there’s a windows service with an issue that’s occasional, or takes some time to build up.
I’m going to have to try changing compiler settings, move some things between root and xmem again and see if my issues come back in win 7 compat and with the windows service off.