This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Invalid CIO command (8) in the CIO buffer at address (0x20002000) was not recognized. Please check the device and program memory maps.

Other Parts Discussed in Thread: LM3S8971

I am receiving the following error when trying to print to the console during debugging using printf("Testing\n"):

Invalid CIO command (8) in the CIO buffer at address (0x20002000) was not recognized. Please check the device and program memory maps.

The string I am attempting to print does print in the console correctly, followed by repeating lines of the above error.

 E.g.

Testing

Invalid CIO command (8) in the CIO buffer at address (0x20002000) was not recognized. Please check the device and program memory maps.

Invalid CIO command (8) in the CIO buffer at address (0x20002000) was not recognized. Please check the device and program memory maps.

...repeat "Invalid CIO command (8)..."

I have my heap and stack set to 4k.  I am using CCS V4.2 with a Stellaris LM3S8971 and a TI ICDI JTAG debugger.

What is causing this error?

 

 

 

  • Ivek,

    A quick bit of background: printf and related functions work by writing a command and data into a buffer and then hitting a software breakpoint.  The debugger reads and interprets the data and does something (such as printing out a string) and then re-runs the target.  That error means that the command in the buffer is meaningless.

    Because the string is first printed out correctly, I'm wondering if the driver is having trouble running from the breakpoint after.  If it is, the debugger would see it as the target hitting the breakpoint a second time, but with the same data (and since the debugger writes data back, the data would look invalid the second time).  If you set a breakpoint in that area of code and hit it, can you run past it to another breakpoint, or are you stuck hitting the same breakpoint over and over until you step or clear?

    Darian

  • It appears that my target is resetting after the breakpoint.  When I use a breakpoint, it keeps going back to the breakpoint.  When I place a new breakpoint ahead of the breakpoint in sequence, it goes to it - which can only happen upon a reset.  I will look at my debug settings and see if there is a reason for the reset.  Thanks for the info on the printf() using a breakpoint.

  • I was able to get rid of the reset by removing the code that enables the watchdog for a reset.  I stepped through the code, and I am unable to step over the printf("Testing\n") line.  As soon as I step over the line, the debugger starts scrolling out the error line in the console and does not return.  If I halt it, and press Step Over, it steps through somewhere in assembly code.  If I halt it, and press Run, it seems to get through to the rest of the code.

  • Darian, Ivek,

     

    Did you get rid of the problem ? Infact I am having similar problem. I am not able to print anything on the terminal, as soon as it hits a printf statement

    it starts flooding C I/O errors, exactly the same error you got.

    Can you suggest some settings in the CCS or point where may be the problem.

     

     

    Regards

    Ajay

     

     

     

     

  • Hi, folks,

    I have

    Invalid CIO command (36) in the CIO buffer at address (0xc009a3c0) was not recognized. Please check the device and program memory maps.

    Is anywhere list of CIO command (error) numbers with their meanings? Or does (36) mean e.g. programme data the CIO function operate with ?

    Thanks

    Radek

     


  • The value stored at address 0xc009a3c0 is 36. The value should be different (I think valid values are supposed to be less than 10). i.e. that value is used to figure out whether CIO command is a printf, scanf, etc.  You need to figure out why 36 is at that address. I would probably start by opening a memory view at that address to confirm that 36 is what is displayed. Beyond this there are many reason why that value could be invalid

    application could be overflowing CIO buffer memory writing invalid values.  

    This region may not be a valid memory for your device

            there maybe a bug in the driver where memory read returns invalid data

            

    Depending you device that you are using you might be able to use a data breakpoint (watchpoint) configurable from breakpoint manager to set a watchpoint at that address to halt the processor when a write occurs, then figure out what piece of code is doing the write. 

     

    martin