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.
I'm getting the following debugger errors when trying to read an I2C register:
ARM9_0: Error: Error 0xA0002020/-140 Error during: Execution, Control, Error generated by SD scan controller module
ICEPICK_C: Error: Error 0xE0002024/-173 Error during: Register, Execution, Control, Error generated by SD scan controller module
From I2C_write in the CSL - I get the errors when I try to step this line:
// Check for NACK Signal
if(CSL_FEXT(i2c0Regs->ICSTR, I2C_ICSTR_NACK) == 1)
This is after many earlier successful reads.
Any clue? This is when trying to talk to an LTC2991.
Are you using your own code or TI provided example ?
It's my own code with CSL stuff "lifted" from TI.
I presume that you are running this code on EVM not custom board ??
OMAPL137EVM from Spectrum Digital connected to an LTC2991 eval board.
Are you getting this error only when you run this code not with other examples, say helloworld ??
Just ran into the error, so haven't had a chance to "backtrack" yet to helloworld examples... will try.
Steve
Getting a different error when using an XDS560v2 JTAG probe - same spot in the code:
ARM9_0: Error: Failed to get PRSC status
ICEPICK_C: JTAG Communication Error: (Error -181 @ 0xFFFFFF4B) The controller has detected a dead JTAG clock. The user must turn-on or connect the JTAG clock for the target. (Emulation package 6.0.228.0)
ARM9_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
Was just using the on-board emulator...
That help???
Still more variations on the error - still same spot in the code:
ARM9_0: Error: Failed to get PRSC status
ARM9_0: Trouble Halting Target CPU: (Error -2062 @ 0x14C3) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.228.0)
ICEPICK_C: Encountered Illegal Op-code: (Error -1 @ 0x0) Internal error: Invalid error code. Restart the application. If error persists, please report the error. (Emulation package 6.0.228.0)
ICEPICK_C: JTAG Communication Error: (Error -181 @ 0xFFFFFF4B) The controller has detected a dead JTAG clock. The user must turn-on or connect the JTAG clock for the target. (Emulation package 6.0.228.0)
ARM9_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
Help at all?
The error is occurring during a pointer de-reference operation in I2C_write:
The exact assembly instruction seems to vary, but it's always the same C source line.
An I2C write has at least two parts: writing the address and then writing the data. The address happens OK when _counter = 0. The data is failing (_counter = 1 in the loop above). Many earlier writes happen OK, too.
This any help?
Hi,
Thanks for your update.
Kindly check the below wiki resource could help you in any way to sort out your issues:
http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Library_error
http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide#Boot_Modes
Also, we found technical note pdf doc. of spectrum digital XDS560v2STM configuration file Sd560v2opts.cfg and the same needs to be validated through basic instructions explored on the below doc. May be, you can check this and I think, the user needs to launch Sd560v2Config utility from the desktop to validate SD emulation drivers which is part of CCS software.
May be, you could check the below.
http://support.spectrumdigital.com/ccs42/Docs/TechNote_11.pdf
Thanks & regards,
Sivaraj K
-------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question
-------------------------------------------------------------------------------------------------------
I'm connected OK to the target. From the Test Connection button in CCS:
[Start: Spectrum Digital XDS510USB Emulator_0]
Execute the command:
%ccs_base%/emulation/drivers/sdjtag.exe -f %boarddatafile% -v -X reset -X scantest
[Result]
** BoardFilePath: C:\Users\STEPHE~1.SAN\AppData\Local\TEXASI~1\CCS\ti\0\0\BrdDat\testBoard.dat
** Resetting Emulator
-- Emulator is Reset
** Emulator Scan Test
-- Found JTAG IR Length of 6
-- Found 1 device(s) in the scan chain
[End: Spectrum Digital XDS510USB Emulator_0]
A strange thing is that on the 'scope, I can see the full I2C write succeed:
ack |= LTC2991_register_write(LTC2991_I2C_ADDRESS, LTC2991_CONTROL_PWM_Tinternal_REG, 0); //LTC2991_REPEAT_MODE); //! Configures LTC2991 for Repeated Acquisition mode
But ... it crashes on the CCS side.
If I reverse the order of the bytes written, it does the incorrect write but doesn't crash: writing 0x10 to address 0x08 is what I need to do. Writing 0x08 to 0x10 works w/o crashing, but is not what I need to do.
The "canned" example works fine...
[ARM9_0] Example: I2C_eeprom_armL137
Scope: I2C writes and reads to the on-board EEPROM.
Begin...
Sending data (by page) to EEPROM...
Receiving data (by page) from EEPROM...
Comparing transfered and received data (by page)...
Results:
Page 0: PASS
Page 1: PASS
Page 2: PASS
Page 3: PASS
End of example.
I've also included the example code in my project as a "sanity check".
The question is why a particular I2C write would fail after so many preceding it succeed??
I asked a couple of questions earlier that I haven't heard an answer on:
What does the "SD scan controller module" message tell you?
What do the error codes (0xE0002024/-173, 0x80002200/-140) mean?
Any help on these?
Thanks.
Steve
I've also seen Error 0x80002004/-173 and 0xA0002020 codes.- any help? One the chance that they're OMAPl137 addresses, I've set HW breakpoints on them, but they never "hit".