> Yes - this is a bug - probably a cut&paste error. > > It looks like, as you say, that there are two errors cancelling out. The > target_read_buffer() function should reference the address variable.
I believe the attached patch fixes that, although I don't have anything using the relevant two RTOSs to test against. > If you need an explanation of any parts of the code, let me know. > You will probably find that eCos stacks register in the same order that > FreeRTOS and ThreadX do on the Cortex-M3 platform. If that is the case, all > you need to do is to implement the reading of the eCos thread list(s). Thanks for the offer, I may take you up on it. eCos appears not to stack the registers in the same way, at least not if I've interpreted http://hg-pub.ecoscentric.com/ecos/file/fac7912b6449/packages/hal/cortexm/arch/current/src/context.S#l64 correctly. I've created a new stacking order, and I've managed to parse the thread list. Unfortunately, issuing "info threads" into GDB doesn't fully meet expectations. It prints the list of threads/names/states/uniqueid, but then hits an assertion failure. "current_thread==-1||!thread_list", I think. I can see that it has requested the stack for two of the four test threads at that point. I'm not near my test machine at the moment, so I haven't got the details to hand. I've got a few more places to look, but if there's any obvious clues I've missed, I'd appreciate the advice. Alan
0001-Correct-stacking-direction-and-use-of-address-offset.patch
Description: Binary data
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
