Hi guys!
Just a thing to consider:
I think the issue might be around the dap implementation. I just read
through the ADI documentation the other day, and it says that if one
uses auto-increment for reading or writing using the MEM-AP, the
incrementation only works for the LSB 10 bits, after that the
behaviour is *undefined*. This struck a heavy wtf in me, that's why I
remember.
Maybe you should check out, if this is the problem.
Regards,
Ákos Vandra
On 16 March 2012 11:33, Drasko DRASKOVIC <drasko.drasko...@gmail.com> wrote:
> On Fri, Mar 16, 2012 at 3:06 AM, 吴亚杰 <yajie...@hotmail.com> wrote:
>> Hi，
>>
>>> Date: Thu, 15 Mar 2012 19:11:45 +0100
>>> From: drasko.drasko...@gmail.com
>>> To: salva...@telecable.es
>>> CC: openocd-devel@lists.sourceforge.net
>>> Subject: Re: [OpenOCD-devel] Bug in mips32_pracc_read_mem32
>>
>>>
>>> On Thu, Mar 15, 2012 at 6:44 PM, salvador <salva...@telecable.es> wrote:
>>> > On 03/14/2012 07:24 PM, salvador wrote:
>>> > 1.- There is no call to mips32_pracc_read_mem32() in
>>> > mips_m4k_read_memory().
>>> Yes, there is. It is called implicitly, by mips32_pracc_read_mem().
>>> Anyway, count parameter is propagated.
>>> Looking in the mips_m4k_read_memory() you can easily see that it is
>>> used to count __BYTES__ :
>>>
>>> t = malloc(count * size * sizeof(uint8_t));
>>>
>>>
>>> > 2.- I guess you mean a call to mips32_pracc_read_mem(). This function
>>> > has a parameter "int size".
>>>
>>> Yes. Size of variable does not meter. It is a placeholder for integer
>>> - a number. This number, however, can be a number of apples, ducks or,
>>> as in this case - bytes.
>>>
>>> >
>>> > 3.- The function mips32_pracc_read_mem() is defined in mips32_pracc.c
>>> > . This function calls mips32_pracc_read_mem32() only if the
>>> > parameter size is 4 (WORD) and count >1.
>>>
>>> Yes. 'size' is the "acces width" : w, hw or b. Independantly, 'count'
>>> is nb of bytes.
>>
>> i think 'count' is not nb of bytes. see the followin code from the function
>> —— mips_m4k_read_memory
>> for(i = 0; i < (count*size); i += size)
>> {
>> switch(size)
>> {
>> case 4:
>> t32 = le_to_h_u32(&buffer[i]);
>> target_buffer_set_u32(target,&buffer[i], t32);
>> break;
>> ......................
>>
>> if 'count' is really nb of bytes, i think the code should be the follwing
>> instead of the above:
>> for(i = 0; i < (count); i += size)
>> .......................
>> In my opinion ,
>> for a "word access" , 'count' is nb of word
>> for a "halfword access" , 'count' is nb of halfword
>> for a "byte access" , 'count' is nb of byte
>
> Looking in target.h comments, this seems to be true...
>
> Salvador,
> what actually happends when you apply your patch ? Does it work
> correctly for more than 1024 words read ?
>
> If yes, can you please post the patch to gerrit ?
>
> BR,
> Drasko
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
