06:02 <jybz> Hello o/

06:24 <PaulFertser> jybz: hey

06:25 <PaulFertser> jybz: if you're lifting the pin to to disconnect flash Vcc from the board Vcc then of course you should power just the flash and connect flash's Vcc to Vtref.

13:28 <Guest51> Hi -- im trying to create a `jtag newtap` configuration for an ADSP-21062lcs. It doesnt have an IDcode so its not as straight forward as i was expecting it to be.

13:28 <Guest51> As i understand it, in the absence of '-expected-id', i need to use '-ircapture' and '-irmask'

13:28 <Guest51> Is that correct? If so -- from what i've read, i need the following configuration (ish)

13:28 <Guest51> To be totally honest im not 100% confident with my value for '-ircapture' (and irmask by extension)

13:28 <Guest51> 'jtag newtap adsp-21062lcs-160 tap -irlen 5 -ircapture 0x10 -irmask 0x1F'

13:28 <Guest51> The parameter values i used above have come from this line in the processors users manual.

13:28 <Guest51> "The instruction register is 5 bits long with no parity bit. A value of 10000 binary is loaded (LSB nearest TDI) into the instruction register whenever the TAP reset state is entered."

13:28 <Guest51> Could someone please confirm i've given the right(or wrong!) parameters based off the information provided? If its wrong -- how?

13:28 <Guest51> If im missing key information to help solve this issue please let me know.

13:28 <Guest51> Log without config: https://pastebin.com/MapEGv5M

13:28 <Guest51> Log with only ep1k30 on the chain: https://pastebin.com/qU5riqGR

13:28 <Guest51> log with ep1k30 and ADSP on the chain: https://pastebin.com/fWjRAk39

13:30 <PaulFertser> Matt144: please add both jtag newtap commands suggest by autoprobing in the same order and retry.

13:38 <Matt144> Thanks -- like this? https://pastebin.com/RB1aj9FF

13:39 <Matt144> If thats the solution im suprised -- i thought i did have it in the right order :)

13:40 <PaulFertser> Matt144: looks ok so far, you might add 0x220601ba instead of 0 expected-id in the first tap specified.

13:41 <Matt144> Thanks so much -- i've been overcomplicating the solution... I thought it was meant to be the in the same order as the chain on the board

13:42 <PaulFertser> Matt144: the documentation talks about the order of the chain, yes, that can be confusing indeed

13:43 <PaulFertser> Probably using 0x220601ba for idcode is just illegal and you should probably ignore the warning and proceed.

13:43 <Matt144> yeah looks like it: https://pastebin.com/QqywdzSs

13:44 <Matt144> thanks again! much appreciated

13:45 <PaulFertser> Matt144: that was easy :)

13:45 <PaulFertser> Welcome

13:46 <PaulFertser> Matt144: what do you plan to do with this setup?

13:47 <Matt144> im still learning openOCD, so bear with me....

13:49 <Matt144> Long story short, thermal camera with 2 chips on it (altera and the ADSP). I don't know what signals to send to the camera to control the focus. I've determined that the Focus motor is driven by a signal sent by the Altera, and theres an RS422 line leading to it. I'm hoping to dump the contents of the attached flash chip so i can figure out what to send via serial

13:51 <Matt144> i could of course just work around this by controlling the focus motor directly but i've got 10 more of these cameras that i want to get working without cracking open (they're filled with nitrogen or something)

13:54 <PaulFertser> Matt144: what the attached flash chip is?

13:56 <Matt144> Intel TE28F008... not 100% sure if its supported TBH. i remember reading something about intel flash and support somewhere... cant find it right now tho

13:57 <Matt144> but TBH im still curious to understand how all this works even if its a waste of time

14:05 <PaulFertser> Matt144: so this flash is memory-mapped parallel flash but not CFI.

14:05 <PaulFertser> Right?

14:06 <PaulFertser> Matt144: but OpenOCD doesn't have any support for SHARC I'm afraid.

14:06 <PaulFertser> Matt144: what's your plan again, is it about dumping the firmware and disassembling it to find functions that handle that RS422 communication to find the details about the protocol?

14:07 <Matt144> Regarding your flash question -- not sure, dont know enough about the field to answer that.

14:07 <Matt144> I dont actually need to get into the SHARC by the looks of the PCB (which is good)

14:07 <PaulFertser> Matt144: and the other side of the line is the Altera FPGA, right? Why do not you just sniff the communication then to see what is being sent there?

14:07 <Matt144> and regarding the plan -- yes exactly that

14:08 <Matt144> The thermal camera gets attached to hardware which i dont have so i cant figure out what to send it by looking

14:09 <PaulFertser> Matt144: I see. Another way to attack this would be to desolder the flash and connect it to an MCU you're familiar with to dump it directly. Or use some ready-made device that knows how to handle it.

14:10 <Matt144> Yeah i did consider that -- however i was hoping some kind of J-tag solution would work without me needing to be (potentially) destructive

14:35 <Matt144> as im progressing further here -- is it even possible to create a target for the Altera TAP here?

14:36 <karlp> if they're connected on a classic jtag chain, sure.

14:37 <Matt144> ok -- silly question then.... How am i meant to know the target type for said FPGA?

14:42 <PaulFertser> Matt144: FPGA is not a CPU target

14:43 <PaulFertser> Matt144: you can talk to it with irscan/drscan or play back SVFs but that's about it.

14:48 <Matt144> i see -- so for my purposes im barking up the wrong tree

14:51 <Matt144> I assumed that since the flash was written to via jtag (via the FPGAs) (presumably) i could also read from it in a similar way

14:52 <PaulFertser> Matt144: why do you think it's FPGA that's writing to flash?

14:53 <PaulFertser> Matt144: or why do you think that flash stores the firmware that the DSP executes?

14:55 <Matt144> By following the traces -- the flash only leads to both FPGAs, vcc and ground. Theres no programming headers for the flash. (Unless the flash was programmed before soldered on to the board...)

14:56 <Matt144> The Altera chip has no onboard persistent storage

14:56 <Matt144> if i remember reading correctly

14:56 <Matt144> so on power-on it has to fetch its data from the flash chip

14:59 <Matt144> i think the only time the FPGA ever wrote to the flash was during the manufacturing process

15:00 <Matt144> actually just to clarify, the flash write enable is wired pinned out just next to the J-tag headers

15:04 <Matt144> let me know if im talking rubbish tho

15:05 <Matt144> i am a little in over my head with this stuff

15:18 <Matt144> ok i see in the docs now openOCD only supports programming FPGA/PLDs

21:40 <PaulFertser> Matt144: reading out the flash of the FPGA won't give you much. You're after the protocol and the protocol is implemented in that DSP, and it stores firmware internally I guess.