No, it's one-bit register.
EJTAG spec :
The width of the Fastdata register is 1 bit. During a Fastdata access,
the Fastdata register is written and read, i.e., a bit is
shifted in and a bit is shifted out. (See Section 6.4.3 on page 91 for
how the Data + Fastdata registers are selected by the
FASTDATA instruction.) During a Fastdata access, the Fastdata register
value shifted in specifies whether the Fastdata
access should be completed or not. The value shifted out is a flag
that indicates whether the Fastdata access was
successful or not (if completion was requested).
With this in mind can you please post code variants of these two functions ?
I am currently implementing A), but this keeps me in the infinite loop :
int mips_ejtag_fastdata_scan(struct mips_ejtag *ejtag_info, int
write_t, uint32_t *data)
{
struct jtag_tap *tap;
tap = ejtag_info->tap;
assert(tap != NULL);
struct scan_field fields;
uint8_t spracc = 0;
uint8_t t[4] = {0, 0, 0, 0};
/* Shift out SPrAcc - Fastdata 1-bit reg */
fields.num_bits = 1;
fields.out_value = &spracc;
fields.in_value = NULL;
jtag_add_dr_scan(tap, 1, &fields, TAP_IDLE);
/* Shift in SPrAcc - check if access will work */
fields.num_bits = 1;
fields.out_value = NULL;
fields.in_value = &spracc;
do
{
jtag_add_dr_scan(tap, 1, &fields, TAP_IDLE);
int retval;
if ((retval = jtag_execute_queue()) != ERROR_OK)
{
LOG_ERROR("register read failed");
return retval;
}
} while (spracc != 1);
/* processor access data register 32 bit */
fields.num_bits = 32;
fields.out_value = t;
if (write_t)
{
fields.in_value = NULL;
buf_set_u32(t, 0, 32, *data);
}
else
{
fields.in_value = (uint8_t *) data;
}
jtag_add_dr_scan(tap, 1, &fields, TAP_IDLE);
return ERROR_OK;
}
What's wrong here and how it should be implemented ?
BR,
Drasko
On Tue, Apr 5, 2011 at 11:32 AM, Laurent Gauch
<laurent.ga...@amontec.com> wrote:
> Drasko DRASKOVIC wrote:
>>
>> On Tue, Apr 5, 2011 at 9:01 AM, Laurent Gauch <laurent.ga...@amontec.com>
>> wrote:
>>
>>>>
>>>> On Mon, Apr 4, 2011 at 7:51 PM, Ųyvind Harboe <oyvind.harboe at
>>>> zylin.com
>>>> <https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote:
>>>>
>>>>>
>>>>> / Any objections to merging 1,2 and 4?
>>>>>
>>>>
>>>> />/
>>>> />/ I think #3 needs more discussion or cool-off. My objection is
>>>> />/ that we don't know why this makes things better and it certainly
>>>> />/ seems to hit performance hard.
>>>> /
>>>> OK, I will open the discussion by question : when do we use
>>>> jtag_execute_queue() ?
>>>> Based on the answer from Ųyvind I had before, I could conclude that it
>>>> serves to clock the data back in, while jtag_add_dr_scan() just puts
>>>> them in the queue to be shifted out at some point.
>>>>
>>>>
>>>
>>> jtag_add_xxxxxxx function will add new commands in the command queue.
>>> Note, the command queue could be auto-executed, depending on the
>>> mechanism/ressource of the JTAG adapter.
>>> The jtag_execute_queue function force the execution of the command queue,
>>> and process the response data coming back from the JTAG adapter.
>>>
>>> Before comparing a TDO vector, you MUST do a jtag_execute_queue.
>>>
>>>>
>>>> So, if this is correct, then we can avoid using jtag_execute_queue()
>>>> when we have no data to shift in. But what happens when the TAP will
>>>> send us bit as a response to FASTDATA, and we are completely ingnoting
>>>> it ? Will it lead to some collision on the data bus and make ftdi
>>>> freak out ?
>>>>
>>>>
>>>
>>> The JTAG layer only scan in and scan out the shift registers, and control
>>> the TAP FSM.
>>> The TAP will only return data if you do a scan .
>>>
>>>>
>>>> Here is EJTAG spec on FASTDATA :
>>>> Both upload and download accesses are attempted by shifting in a zero
>>>> SPrAcc value (to request access completion) and shifting out SPrAcc to
>>>> see if the
>>>> attempt will be successful (i.e., there was an access pending and a
>>>> legal Fastdata area address was used).
>>>>
>>>>
>>>
>>> Actually, two solutions :
>>> a) checking the SPrAcc
>>> 1.send command to shift in zero to SPrAcc (jtag_add_scan)
>>> 2.send command to shift out SPrAcc (jtag_add_scan)
>>> 3.execute (jtag_execute)
>>> 4.compare SPrAcc returned value
>>> 5. if SprAcc not 0 goto 2.
>>> 6. send command to shift in your DATA
>>> -> goto to 1.
>>>
>>> b) unchecking the SPrAcc, but adding specific delay
>>> 1.send command to shift in zero to SPrAcc (jtag_add_scan)
>>> 2.wait for x delay allowing your specific hardware to accept SPrAcc
>>> 3.send command to shift in your DATA
>>> -> goto to 1.
>>>
>>> Note: b)2. the wait could be done by soft, or adding delay in the
>>> command
>>> queue or ...
>>>
>>> A) will be the most secure
>>> B) could be very fast, but should be avoid for generic implementation
>>> (not
>>> safe)
>>>
>>
>> Hi Laurent,
>> this sounds very interesting, and I'd say that in current
>> mips_ejtag_fastdata_scan() implementation we are doing something
>> similar to B), but not quite - we never add the delay. However, this
>> delay is undefined, and might come because of architecture of some
>> dongles, so we may have situation that somewhere it works, and
>> somewhere it does not, right ?
>>
>
> The jtag_execute_queue maybe generate enough delay in some case.
> But not safe, since in the case of USB JTAGkey the latency delay added is
> 1ms, and in the case of USB JTAGkey-2 the latency delay added is 125us ...
> It is much better to work on stable TAP state and generate some CLK periods.
>>
>> Can you please paste here to versions of mips_ejtag_fastdata_scan(),
>> A) (with shifting out SPrAcc) and B) (with added delay) as you
>> described them, so I can try them both and test the results.
>>
>
> Not so many time today, but I would try to out something before the end of
> the week.
>>
>> I would change the code by myself but for A) I do not know - should we
>> use separate field, or SPrAcc can be return in the same field when
>> sent, like this :
>> /* fastdata 1-bit register */
>> fields[0].num_bits = 1;
>> fields[0].out_value = &spracc;
>> fields[0].in_value = &r;
>> But this does not work.
>>
>
> I have to see again MIPS TAP,.
> Are you sure about the
>
> fields[0].num_bits = 1;
>
> Does the register not longer, and need to check one bit ???
>
>> And for B) I do not know which function we can use for delay ? Maybe
>> jtag_add_clocks() ?
>>
>> The best thing would be here if you can paste these two variants, and
>> I will integrate them, test them and report the results.
>>
>> Best regards,
>> Drasko
>>
>
> Regards,
> Laurent
> http://www.amontec.com
>
>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
