On Wed, Jun 29, 2011 at 3:43 PM, Andreas Fritiofson
<andreas.fritiof...@gmail.com> wrote:
>
>
> On Wed, Jun 29, 2011 at 9:17 PM, Rodrigo Rosa <rodrigorosa...@gmail.com>
> wrote:
>>
>> On Wed, Jun 29, 2011 at 12:44 AM, Øyvind Harboe <oyvind.har...@zylin.com>
>> wrote:
>> > This is disturbing. Why switch to global variables?
>> >
>> > +static uint32_t data_read_dummy;
>> >  static int jtag_data_write(struct target * target, uint32_t instr,int
>> > num_bits, uint32_t * data_read){
>> >   int retval;
>> > -  uint32_t data_read_dummy;
>> >
>>
>> i did this to have mem to dump the data read at the time the queue is
>> flushed
>> i do not care about this data, but i need somewhere to dump it
>> (otherwise it'll segfault). multiple instances of the target would not
>> cause trouble, since i do not care about this data, so it could be
>> overwritten and it would no break anything.
>
> It should be safe to pass null as read pointer if you want to discard the
> data from the scan. This is also explicitly stated in dsp5680xx_drscan().
> However, jtag_data_write does use the data:
>   if(data_read != NULL)
>     *data_read = data_read_dummy;
> This doesn't seem right, because the queue hasn't been executed yet and so
> data_read_dummy has a bogus value. Bug?
> /Andreas

jtag_data_write calls dsp5680xx_drscan, and dsp5680xx_drscan executes the queue.
when dsp5680xx_drscan does execute the queue then the data that is
read is bogus.
i only disabled flushing the queue when i'm in write loops, where i do
not care about the data read out the the drscan.
all the read commands work correctly, and the writing commands that
use the data always execute the queue (context.flush==1)

the dsp568013 return the value of the status register when you execute
any instruction, that's why i added the possibility of pulling out the
data from a write command (to avoid reading the register explicitly)

thanks.

-- 
Rodrigo.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to