| 02:14.35 | *** join/#openjtag rwhitby` (n=rwhitby@ppp240-74.static.internode.on.net) |
| 08:07.35 | *** join/#openjtag LaptopDragon (n=david@whipy.demon.co.uk) |
| 08:41.32 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 09:20.12 | *** join/#openjtag pleemans_ (n=peter@d51A5E76A.access.telenet.be) |
| 09:36.24 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 12:58.52 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 14:18.14 | *** join/#openjtag rwhitby` (n=rwhitby@ppp240-74.static.internode.on.net) |
| 14:24.18 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 16:17.06 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 16:58.58 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 19:18.34 | *** join/#openjtag LaptopDragon (n=david@whipy.demon.co.uk) |
| 19:25.26 | drath | prpplague: iirc you mentioned the shap lh7axxx once - have you used that processor? |
| 19:46.01 | *** join/#openjtag drath_ (i=vmaster@p5B07D820.dip.t-dialin.net) |
| 20:01.31 | prpplague | drath: indeed, we did a complete design using the LH7a400 |
| 20:01.37 | prpplague | drath: as well as the LH79520 |
| 20:06.22 | drath | prpplague: heh, any chance you remember if it was possible to debug that processor out of reset? i briefly browsed the user's manual and datasheet and found little information on JTAG and the reset lines on that proessor |
| 20:07.36 | prpplague | drath: i don't recal, but i do know that the JTAG is NOT ieee compliant |
| 20:08.13 | drath | ahh, yeah, i remember you and/or beewoolie discussing this |
| 20:28.02 | prpplague | drath: sorry boss was at my desk |
| 20:28.10 | prpplague | drath: yea, sampling is all wrong |
| 20:28.27 | prpplague | drath: plus i do know the nRESET and nTRST had issues |
| 20:33.43 | drath | prpplague: ok, thx |
| 20:34.20 | drath | prpplague: an openocd user has a problem with completely bogus flash, and can't read or write any memory, not even internal SRAM |
| 20:34.48 | drath | prpplague: but without reliable ntrst and nsrst it's difficult to get the processor into a known state |
| 20:37.40 | prpplague | indeed |
| 20:38.01 | prpplague | drath: basically what we would have to do is hold the reset down while powering on the device |
| 20:38.53 | prpplague | drath: one of the problems is that is if the flash is blank, i.e. 0xff is stored in the locations, when the cpu starts it tries to execute 0xff which is considered an invalid op |
| 20:39.05 | prpplague | drath: and basically locks the processor |
| 20:39.38 | prpplague | drath: unless the board has good control of both nRESET and nTRST you are going to have problems |
| 20:39.44 | drath | prpplague: yeah - sometimes a jtag debugger is able to connect in these cases, but that's just luck |
| 20:40.16 | prpplague | drath: sharp/nxp's recommended fix is to tie both nRESET and nTRST together |
| 20:40.18 | drath | prpplague: anyway, i'll see what the user replies, maybe he manages to get "reset halt" working |
| 20:40.22 | prpplague | drath: indeed just luck |
| 20:40.23 | drath | prpplague: lol |
| 20:40.30 | drath | prpplague: that certainly doesn |
| 20:40.32 | drath | 't help |
| 20:40.35 | prpplague | indeed |
| 20:41.04 | prpplague | which is why i complain about sharp's support of such issues |