BDI2000仿真器常见问题“问与答” (连载一)

一、ARM处理器

1. Flash相关问题

问题： A101 映像文件没有被烧写或者下载到正确的地址上

映像文件没有被烧写或者下载到正确的地址上。 换句话说: 当执行了下载或者烧写到存储器的指令后, 映像文件被写在了错误的地址上。（Image not being programmed or loaded at the correct memory address. Doing a load or prog into memory results in the image being put at the wrong memory location.）

回答：在你做进一步操作之前，请检查你的闪存/内存是否工作正常.

Before going any further please check if the flash/memory location is working properly. Perform a few writes and reads from the memory location, use MMH for 16bit, MMB for 8 bit, and MMD for 64 bit flash.

MM 0xff000000 0x12345678

MD 0xff000000

If you can write successfully to your target flash or memory then the issue is probably your program image. Always make sure you use the "load" command to write to memory and the "prog" command to burn into flash.

The BDI displays a message saying "loading file to offset 0x0010000", if you find that the address displayed saying loading or programming is not correct then this points to your file not being built correctly for programming flash or loading into memory. You have to make two distinct images depending on whether you want it loaded into sdram or programmed into flash.

The BDI puts the loaded program into memory or flash from information that is built into the file itself. Do an "objdump -p -h -f filename.elf" from a Linux prompt to see where the BDI is being told to load/prog the file. The BDI will load the file according to information built into the program header, not the section headers, so be sure to keep this distinction in mind when looking at the data presented from objdump.

The BDI will ALWAYS put the file where it is told to, so whenever you think that the image is not being loaded to the correct location, remember that the BDI is only doing what it is instructed to. If the BDI can''t write to a location it will come back with an error.

If you find that the image is built correctly but the data is shifted around after you write to the target ram, it is possible that the ram initializations are bad and the address line multiplexing is set incorrectly. Please check this in your config file or board boot up code. If something similar happens in flash then it is possible you have your FLASH data lines reversed. Please see FAQ-P103.

If you are using an SRECORD file and have this issue then please open the SRECORD file with a text editor and make sure it is built properly, use http://www.amelek.gda.pl/avr/uisp/srecord.htm as a reference. If the Checksum in any of the SRECORDS is incorrect the BDI assumes that it is a Binary file and just loads/ programs the file without any of the SRECORD offsets. The result is that file is put into a wrong location in memory, at 0x00000000, along with incorrect data as even the header information is programmed.

问题： A102 闪存编程失败

我从BDI2000的提示中得到如下信息“闪存编程失败（Flash Programming Failed）”，我要如何设置我的闪存编程选项？（I keep getting the message "Flash Programming Failed" in the BDI2000. How do I setup my Flash Programming?）

回答：有几种原因导致闪存编程失败。最经常遇到的就是闪存编程的配置文件设置不正确。

There are several reasons that flash programming could be failing. The most common one is that the config file is not setup correctly for flash programming. Since the BDI uses the processor to perform its flash programming, it is important the memory controller and flash be actually working before the BDI can be used to program flash. Therefore, the burden falls on the developer to customize the BDI config file to properly initialize his board so that flash is properly configured. As a starting point read FAQ A403, on how to make a config file. The following points can be used to analyze if the flash programming is failing because of a bad config file or a bad programming file. Please comment out the WORKSPACE line from the [FLASH] section unless otherwise stated in the manual. Always make sure you use the "load" command to write to memory and the "prog" command to burn into flash.

1.) First of all you need to make sure that the [FLASH] section of the config file is setup correctly, please look at http://www.abatron.ch/Files/Flashsupp.pdf and construct your [FLASH] section with the proper CHIPTYPE, CHIPSIZE and BUSWIDTH.

2.) A very common mistake in making config files is to not have them write protected or not setting the correct bus width or flash size during the memory controller initialization. Please double check the config file [INIT] section and make sure the flash has been properly defined to match what is on your board.

3.) Next we can try to see if basic communication is possible with your flash. From the

BDI2000 use an "md 0x0f000000" and see if you can read back from your flash, where 0x0f000000 is the location of your flash. Use mdd for 64bit, md for 32bit, mbh for 16bit, and mdb for 8bit flash configurations. If this command does not read back flash, either flash is not located at this address or you need to go back and do more work to the flash initialization in your config file.

4.) If you are using an Intel or AMD flash you can try and write the flash command strings into the flash using the "mm" command. See if you can erase then write values into flash. If this works and the displayed values using the "md" are as expected you have verified that your config file is setup correctly. The strings to write in for the erase unlock and write commands are given in your flash datasheet. Remember that this has to work before the BDI2000 will be able to program or erase the flash. If these steps work then you have verified that you can now use the BDI2000 to flash your chip and that your initialization of the flash is correct and working.

For 2 16 bit Intel Strata Flash with a 32bit wide bus try the following stings:

Unlock a block:

BDI> mmh 0x??000000 0x00600060 ; Block unlock at 0x??000000

BDI> mmh 0x??f000000 0x00d000d0 ; Block Verify at 0x??000000

BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction

BDI> mdh 0x??000000 ; shows the Flash data

Erase a sector:

BDI> mmh 0x??000000 0x00200020 ; Block Erase at 0x??000000

BDI> mmh 0x??000000 0x00d000d0 ; Block Verify at 0x??000000

BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction

BDI> mdh 0x??000000 ; shows the Flash data

Program a 32 Word:

BDI> mmh 0x??000000 0x00400040 ; Byte Write at 0x??000000

BDI> mmh 0x??000000 0xabcd1234 ; Write abcd at 0x??000000

BDI> mmh 0x??000000 0xffffffff ; Terminate Transaction

BDI> mdh 0x??000000 ; shows the Flash data

For a 16 bit Amd AM29LV Flash try the following strings:

Erase the entire chip:

BDI> mmh 0x??00AAAA 0xAAAA

BDI> mmh 0x??00555 0x5555

BDI> mmh 0x??00AAAA 0x8080

BDI> mmh 0x??00AAAA 0xAAAA

BDI> mmh 0x??00555 0x5555

BDI> mmh 0x??00AAAA 0x1010 ; Erase Chip

BDI> mdh 0x??000000 ; Shows the status, analyze it

Erase a sector:

BDI> mmh 0x??00AAAA 0xAAAA ; Command Sting must be

BDI> mmh 0x??00555 0x5555 ; entered at a predefined

BDI> mmh 0x??00AAAA 0x8080 ; address ending with AAAA or

BDI> mmh 0x??00AAAA 0xAAAA ; 5556 as shown. You finish by

BDI> mmh 0x??00555 0x5555 ; specifying the address of the

BDI> mmh 0x??000000 0x3030 ; Sector to erase.

BDI> mdh 0x??000000 ; Shows the status, analyze it

Program a 16 word:

BDI> mmh 0x??00AAAA 0xAAAA ; after the command string you

BDI> mmh 0x??00555 0x5555 ; can specify any 16word

BDI> mmh 0x??00AAAA 0xA0A0 ; aligned address to write to.

BDI> mmh 0x??000000 0xabcd ; Write abcd at 0x0f000000

BDI> mdh 0x??000000 ; Shows the status, analyze it

BDI> mmh 0x??00AAAA 0xAAAA

BDI> mmh 0x??00555 0x5555

BDI> mmh 0x??00AAAA 0xA0A0

BDI> mmh 0x??002000 0xabcd ; Write abcd at 0x??002000

BDI> mdh 0x??002000 ; Shows the status, analyze it

The Spansion S29GLxxxM Flash does not support single byte programming. In 8-bit mode, programming is only possible via the write buffer. Therefore programming work only with workspace. The BDI does not support programming via write buffer without a workspace. It uses singe byte programming in this case. You may manually try to program some bytes via the write buffer. For example 4 bytes at 0xff801000:

BDI> mmb 0x??00aaaa 0xaa

BDI> mmb 0x??005555 0x55

BDI> mmb 0x??001000 0x25 ;write to buffer

BDI> mdb 0x??001000 3 ;bcnt - 1

BDI> mmb 0x??001000 0x12 ;data 0

BDI> mmb 0x??001001 0x34 ;data 1

BDI> mmb 0x??001002 0x56 ;data 2

BDI> mmb 0x??001003 0x78 ;data 3

BDI> mmb 0x??001000 0x29 ;program

BDI> mdb 0x??001000

As mentioned, please refer to the flash data sheet for the exact command strings to use.

If the command strings fail to program flash then you need to make sure that the flash is initialized correctly. Also, make sure to account for any bit reversal or byte swapping when typing in the command strings.

5.) Once you have verified that writing to flash is possible, try and erase some sectors on your flash using the "erase 0x0f000000 0x20000 1" command, where 0x20000 is the sector size as given in the flash datasheet. If you have multiple flash chips connected in parallel the sector size will then be the sector size of one chip multiplied by the number of flash chips in parallel. If you get the message "erasing flash failed", then this indicates a problem with the [FLASH] section of the config file or that your flash is write-protected. For Intel flash unlock the flash by either writing the unlock command through the config file, the "mm" commands or using "unlock".

i. A common mistake is to not have the correct buswidth selected. Please recheck the BR0/OR0 or flash initialization to confirm that the proper BUSWIDTH and CHIPTYPE are used.

ii. Also, make sure there is no bit reversal or byte swapping on the flash data bus which can also cause programming to fail. The BDI''s programming algorithm needs to be told to account for your flash configuration. See http://www.ultsol.com/faq-P103.htm for details.

6.) Most flashes need to be erased before they can be programmed. To test that you can program the flash, create a sample binary test file; write in "abcd" into it and save it. This creates a 4byte binary file. Now program it into the flash thru the BDI "prog 0x0f000000 abcd.bin BIN" where 0x0f000000 is the location of your flash. If necessary, create bigger and bigger binary files to test programming of multiple sectors to make sure all sectors of the Flash are programmable. If this works and you verify that the flash is written properly with the "mm" command then everything should be setup correctly for you to burn in an image to your board.

7.) If upon reading back the "mm" command you see corrupted data you need to go back and recheck the flash initialization in the config file, and make sure that the Flash is connected to the processor in a supported manner.

8.) If you have verified that you can program in the sample file correctly, but your own custom file fails, then most likely there is a problem in the file you are trying to program. Try and change into a Binary file format and try programming the file. Srec''s and ELF file formats have some internal offsets built in. You have to understand how the offsets work, for an ELF file for instance you cannot program it by specifying in an initial offset of your own during programming. Doing that will move all the built in linker pointers and will make the ELF file useless. The info of where to program is built directly into the ELF file when it is created, the BDI will program the ELF file based on this information, no additional offset is required by you. To see where the ELF file is being programmed or loaded you can do an object dump from a Linux prompt, "[linux#] objdump -p -h -f yourfile". This will give you all the header and section information. If you find that some sections are being programmed to the wrong address you will need to change the linker script that creates the ELF file to program the header information correctly. The BDI displays a message saying "programming file to offset 0x0010000", if you find that the address displayed during programming is not correct then this points to your file not being built correctly for programming flash .

9.) If you are having trouble where flash programming seems intermittent where it fails sometimes and other times it passes, this maybe an issue with flash timing. Try adding more wait delays in the flash initialization in the [INIT] section of the config file.

10.) If you have a CPU frequency defined in your config file (for some ARM and ColdFire targets), make sure it matches the frequency of your target processor otherwise you can end up with problems programming and erasing flash.