Closed zcsahok closed 8 years ago
dlbeer
commented
8 years ago Thanks for that. Note that 0x1000 isn't universally correct either, but I think it's probably better to err on the side of breaking RAM writes rather than flash writes. If we were to fix this correctly, we'd have to look up the chip database for the correct boundary.
zcsahok
commented
8 years ago Yes, now chip identification is done in fet3 driver only. Would you mind to move it device.c, i.e. extend device_probe_id function? chip_id (probably along with jtag_id) needs then to be added to device_t. Part of the code from fet3.debug_init would be then called in a callback function after successful identification. I think it would be surely a useful improvement, even though it requires quite a lot of changes in the code. I can do most of it if that's fine with you.
Zoltan
On Sat, Oct 17, 2015 at 04:46:44PM -0700, Daniel Beer wrote:
Thanks for that. Note that 0x1000 isn't universally correct either, but I think it's probably better to err on the side of breaking RAM writes rather than flash writes. If we were to fix this correctly, we'd have to look up the chip database for the correct boundary.
Reply to this email directly or view it on GitHub: https://github.com/dlbeer/mspdebug/pull/2#issuecomment-148961467
dlbeer
commented
8 years ago On Sun, Oct 18, 2015 at 10:43:01AM -0700, Zoltan Csahok wrote:
Yes, now chip identification is done in fet3 driver only. Would you mind to move it device.c, i.e. extend device_probe_id function? chip_id (probably along with jtag_id) needs then to be added to device_t. Part of the code from fet3.debug_init would be then called in a callback function after successful identification. I think it would be surely a useful improvement, even though it requires quite a lot of changes in the code. I can do most of it if that's fine with you.
Hi Zoltan,
Yes, I think that'd be a useful change. Why do you need a callback though? Couldn't you just have a function which, given the ID data, returned a (const) pointer to an entry in the chip database?
Cheers, Daniel
Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
zcsahok
commented
8 years ago Hi Daniel,
I was looking at fet3.debug_init and there are - after calling v3hil_identify - further operations done (v3hil_configure and v3hil_update_regs). I'd move v3hil_identify call up to device.c (i.e. debug_init returning after v3hil_start_jtag). So the rest of the function needs to be called somehow. A simple option would be a callback, sort of set_chipid(). So core evaluates and sets chipid and the tells the specific driver to take any neccessary further actions. Goodfet and PIF need nothing to do, I just don't want to break FET. Btw I have only a F1232 chip to play with using a PIF adapter or my own goodfet port to Arduino (https://github.com/zcsahok/goodfetuino).
Cheers, Zoltan
On Sun, Oct 18, 2015 at 01:15:34PM -0700, Daniel Beer wrote:
On Sun, Oct 18, 2015 at 10:43:01AM -0700, Zoltan Csahok wrote:
Yes, now chip identification is done in fet3 driver only. Would you mind to move it device.c, i.e. extend device_probe_id function? chip_id (probably along with jtag_id) needs then to be added to device_t. Part of the code from fet3.debug_init would be then called in a callback function after successful identification. I think it would be surely a useful improvement, even though it requires quite a lot of changes in the code. I can do most of it if that's fine with you.
Hi Zoltan,
Yes, I think that'd be a useful change. Why do you need a callback though? Couldn't you just have a function which, given the ID data, returned a (const) pointer to an entry in the chip database?
Cheers, Daniel
Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
Reply to this email directly or view it on GitHub: https://github.com/dlbeer/mspdebug/pull/2#issuecomment-149043428
dlbeer
commented
8 years ago On Sun, Oct 18, 2015 at 01:48:07PM -0700, Zoltan Csahok wrote:
I was looking at fet3.debug_init and there are - after calling v3hil_identify - further operations done (v3hil_configure and v3hil_update_regs). I'd move v3hil_identify call up to device.c (i.e. debug_init returning after v3hil_start_jtag). So the rest of the function needs to be called somehow. A simple option would be a callback, sort of set_chipid(). So core evaluates and sets chipid and the tells the specific driver to take any neccessary further actions. Goodfet and PIF need nothing to do, I just don't want to break FET. Btw I have only a F1232 chip to play with using a PIF adapter or my own goodfet port to Arduino (https://github.com/zcsahok/goodfetuino).
Hi Zoltan,
It might pay to have a look at how the Olimex identification procedure works. It's likely a lot less complicated than the current code makes it look. I'm reasonably sure you could get this implemented just by reading a bunch of bytes from a fixed location and feeding it to a lookup function to obtain chip information. No need for callbacks or anything like that, because the flow should be identical and simple for each chip/driver.
Cheers, Daniel
Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
Hi Daniel,
Just a minor fix: goodfet driver assumed that flash starts at 0x8000.
Thanks for the nice tool.
Zoltan