On 19/03/20 7:20 pm, Rasmus Villemoes wrote:
> On 19/03/2020 14.23, Vignesh Raghavendra wrote:
>>
>
>>> For the read side, it seems that just replacing the UINT_MAX in the two
>>> copies of spi_nor_read_data with some smaller constant should suffice.
>>> But I don't know if I should make that
On 19/03/2020 14.23, Vignesh Raghavendra wrote:
>
>> For the read side, it seems that just replacing the UINT_MAX in the two
>> copies of spi_nor_read_data with some smaller constant should suffice.
>> But I don't know if I should make that smaller constant a CONFIG_*
>> option or just pick
On 19/03/20 6:14 pm, Rasmus Villemoes wrote:
>> Hmm, Watchdog seems to be set to trigger after ~2s of inactivity. Isn't
>> that too small? WATCHDOG_RESET() resets only once per second, so 2
>> second timeout is too close IMO.
>>
>> Typical watchdog timeouts are usually in tens of seconds
>
On 19/03/2020 13.28, Vignesh Raghavendra wrote:
>
>
> On 19/03/20 5:09 pm, Rasmus Villemoes wrote:
>> On 19/03/2020 12.25, Vignesh Raghavendra wrote:
>>> Hi,
> [...]
@@ -399,6 +400,7 @@ static int spi_nor_ready(struct spi_nor *nor)
{
int sr, fsr;
+
On 19/03/20 5:09 pm, Rasmus Villemoes wrote:
> On 19/03/2020 12.25, Vignesh Raghavendra wrote:
>> Hi,
[...]
>>> @@ -399,6 +400,7 @@ static int spi_nor_ready(struct spi_nor *nor)
>>> {
>>> int sr, fsr;
>>>
>>> + WATCHDOG_RESET();
>>
>> Is it necessary to reset watchdog for every status
On 19/03/2020 12.25, Vignesh Raghavendra wrote:
> Hi,
>
> On 17/03/20 1:48 am, Rasmus Villemoes wrote:
>> I have a board for which doing "sf erase 0x10 0x8"
>> consistently causes the external watchdog circuit to reset the
>> board. Make sure to pet the watchdog during slow operations
Hi,
On 17/03/20 1:48 am, Rasmus Villemoes wrote:
> I have a board for which doing "sf erase 0x10 0x8"
> consistently causes the external watchdog circuit to reset the
> board. Make sure to pet the watchdog during slow operations such as
> erasing or writing large areas of a spi nor flash.
7 matches
Mail list logo
