Edgar Grimberg wrote:
>> I see what you are saying, but if the user runs the default script then the
>> write protection will always be removed.
>>
>> this assumes you are reseting with reset init.
>
> Yes, but I trust the user to be smart enough to try a lot more combinations
> than I can imagine
> I see what you are saying, but if the user runs the default script then the
> write protection will always be removed.
>
> this assumes you are reseting with reset init.
Yes, but I trust the user to be smart enough to try a lot more combinations
than I can imagine. Inaccurate information will ap
Edgar Grimberg wrote:
>> The str7 write protection is a bit quirky as once set can only be removed
>> temporarily anyway - until the next reset.
>
> I'm thinking more of this situation:
>
> * I reset and try to write something to the flash
> * It will fail, since the protection is on.
> * I check
> The str7 write protection is a bit quirky as once set can only be removed
> temporarily anyway - until the next reset.
I'm thinking more of this situation:
* I reset and try to write something to the flash
* It will fail, since the protection is on.
* I check the flash, with flash info 0, I see
Edgar Grimberg wrote:
>> Ah ok, I think this is an issue with the str7, rather than openocd.
>>
>> The flash protection is being removed (until next reset) but we are reading
>> the non-volatile register (FLASH_NVWPAR).
>>
>> This is read at reset and any write to this register only effects the
>>
> we can, but it is only valid from the last reset.
> Any changes made to FLASH_NVWPAR will not be viewable, even though
> internally they are working.
I am a bit concerned that I see invalid information when I type "flash info 0"
and no warning that I'm looking at something invalid.
On the same n
Edgar Grimberg wrote:
>> Ah ok, I think this is an issue with the str7, rather than openocd.
>>
>> The flash protection is being removed (until next reset) but we are reading
>> the non-volatile register (FLASH_NVWPAR).
>>
>> This is read at reset and any write to this register only effects the
>>
>
> Ah ok, I think this is an issue with the str7, rather than openocd.
>
> The flash protection is being removed (until next reset) but we are reading
> the non-volatile register (FLASH_NVWPAR).
>
> This is read at reset and any write to this register only effects the
> volatile version of FLASH_N
Edgar Grimberg wrote:
> Hi Spen,
>
>> Could you provide a full debug log?
>
> For the commands:
>
>> debug_level 3
> debug_level: 3
>> flash protect 0 0 last off
> cleared protection for sectors 0 through 7 on flash bank 0
>> flash protect_check 0
> successfully checked protect state
>> flash in
Hi Spen,
>
> Could you provide a full debug log?
For the commands:
> debug_level 3
debug_level: 3
> flash protect 0 0 last off
cleared protection for sectors 0 through 7 on flash bank 0
> flash protect_check 0
successfully checked protect state
> flash info 0
#0 : str7x at 0x4000, size 0x000
Edgar Grimberg wrote:
> Hi,
>
> The information presented by flash info about the protection status
> points to something faulty. My target is a HITEX STR710 evalboard.
> I am using v0.4.0-rc1-154-g3172be8 . The configuration script is the
> default one from target/str710.cfg
> This is the test ca
> Whoops, sorry -- that one isn't listed as "regression"[1],
> nobody has confirmed that it was working in 0.3.1 code.
How about we try using a bug database of sorts? Mantis is the first
that comes to mind. It can be read-only for the general public and
only the maintainers (and "official testers"
On Thursday 28 January 2010, David Brownell wrote:
> On Thursday 28 January 2010, Edgar Grimberg wrote:
> > The information presented by flash info about the protection status
> > points to something faulty.
>
> This is on my list of regressions. Someone with an STR7
> should come up with a fix .
On Thursday 28 January 2010, Edgar Grimberg wrote:
> The information presented by flash info about the protection status
> points to something faulty.
This is on my list of regressions. Someone with an STR7
should come up with a fix ...
___
Openocd-dev
Hi,
The information presented by flash info about the protection status
points to something faulty. My target is a HITEX STR710 evalboard.
I am using v0.4.0-rc1-154-g3172be8 . The configuration script is the
default one from target/str710.cfg
This is the test case:
> flash protect_check 0
success
15 matches
Mail list logo
