首先nor flash的移植已经成功了,这回尝试采用cfi接口。

    定义了几个宏之后可以正确识别flash的容量和型号了,但是发现用saveenv命令时提示写超时,这回纠结了,看写nor_flash的代码,看不太明白,云里雾里的,唉!接着用移植好的代码替换出错的代码一步步排查错误,将有关擦除和写的代码都替换了,这回不报错了,但是环境变量还是没有保存,这就奇怪了。最后我灵机一动,忽然想起了在调试过程中用debug调试时有的debug会导致不停的打印写的信息,这回我在头文件中将所有debug关掉,环境变量可以保存了,接着我将代码恢复到“写超时”的版本,也没有问题了,我觉得就是debug破坏了写的时序造成的,debug虽好,用时需谨慎啊!


造成写超时的原因:

Erase timeout 16384 ms, write timeout 1 ms, buffer write timeout 1 ms, buffer size 1

这是利用cfi接口查出的数据,但是我看mx29lv160db的手册并不是这个值啊,典型值是11微秒,最大才360微秒。不管了,反正这个值远大于手册上的。就先按这个算吧!

u-boot-1.1.6之nor flash移植错误

代码如下:

static int flash_status_check (flash_info_t * info, flash_sect_t sector,
                   ulong tout, char *prompt)
{
    ulong start;
//其中CFG_HZ按照smdk2410.h中的设置为1562500,也就是定时时间为1秒
#if CFG_HZ != 1000
    tout *= CFG_HZ/1000;
#endif
    /* Wait for command completion */
    start = get_timer (0);
    while (flash_is_busy (info, sector)) {
        if (get_timer (start) > tout) {//判断等待命令完成期间是否超时,tout的值为1562,相当于定时器4时间大约为1ms
            printf ("Flash %s timeout at address %lx data %lx\n",
                prompt, info->start[sector],
                flash_read_long (info, sector, 0));
            flash_write_cmd (info, sector, 0, info->cmd_reset);
            return ERR_TIMOUT;
        }
        udelay (1);        /* also triggers watchdog */
    }
    return ERR_OK;
}

    现在重点来了,在flash_is_busy函数中有:debug ("flash_is_busy: %d\n", retval);

    当串口的波特率为115200时,1ms最多传输11.52byte的字符,取整为11byte,而debug中输出的字符有16个,输出时间肯定大于1ms,即调用flash_is_busy函数返回后,get_timer (start)的必定大于tout导致超时。这就可以解释为什么将debug开关关掉程序就正常的原因了。

相关文章:

  • 2022-12-23
  • 2021-11-30
  • 2022-02-13
  • 2021-07-04
  • 2021-08-08
  • 2021-10-25
  • 2022-12-23
猜你喜欢
  • 2022-12-23
  • 2021-05-31
  • 2022-12-23
  • 2021-06-04
  • 2022-12-23
  • 2021-05-15
  • 2021-06-03
相关资源
相似解决方案