The most important issues to pay attention to during ARM development

　　I read the nk.bin file on the HARD DISK in EBOOT, and then load the WINCE system from the HARD DISK. In this process, there is always a check sum error, but there is no error when downloading from Ethernet, so the problem should still be in the part of the code I added, and the same code can run normally on the PC. After checking the logical relationship of the code, it is correct. Then I printed out all the data with debugging information when the error occurred, and found that the 4096th byte from the beginning of the file was lost, while the other bytes were correct. The initial judgment was that the problem was caused by alignment, so I checked each BUFFER, and finally found that when reading the hard disk data, BUFFERR was not aligned according to double bytes, and the hard disk read the data in 16BIT, which caused the error.

In fact, this kind of problem is very common on ARM systems, and it is hard to guard against. The following are some of my examples.

1. Always pay attention when parsing the data stream. If you need to convert a data stream (BUFFER) into a structure to retrieve values, you should define the structure as byte-access. Consider the following structure:

struct a{

char a;
short b;
long c;
};
If a data stream contains such a structure, and we want to directly convert the pointer of the data stream into the pointer of the structure, and then directly retrieve the value of the structure member, we should define the structure as byte-access, that is, sandwich it between the statements
#pragma pack(push,1)
...

#pragma pack(pop)
. If we don't do this, the compiler will align the address of member b to the address of the short pointer, that is, add a char, which is an 8-bit member, after a, and align C to LONG, that is, add another char member after B. In this way, members B and C will not get the correct value.

If we define a normal structure to store some data, we don't need to define it as byte-access. The compiler will add some placeholder members, but it will not affect the operation of the program. In this sense, in ARM, it is meaningless to define structure members as CHAR and SHORT to save memory.

A typical example is the driver of the file system. Files are stored on the storage medium in some defined structures. They are read into a BUFFER. When we access a specific file or directory structure, we will convert the address into a structure and read the value in it.


2. When accessing peripherals.
For example, the disk driver usually accesses data in 16BIT mode, that is, two bytes are accessed each time. This requires that the BUFFER passed to it is double-byte aligned. The driver should make correct processing of the pointer sent from the upper layer to ensure the correctness of the data.


3. Sometimes, we do not convert the data stream pointer into a structure pointer to obtain the value, but if we read double-byte or four-byte data, we also need to pay attention to the alignment problem. For example, if a four-byte value is read from a BUFFER at offset 10, the actual value obtained is the
DWORD value at the address at offset 8.

How to install driver in wince

 I have mentioned how to install wince on the development board. Now I have a USB camera. In order to use it on the development board, I have to install the driver. The manufacturer provides the dll and the instructions for modifying the registry. The following are the steps.

    Open the project where you customized the wince kernel and copy the driver file, let's say it's called A.dll, to the project directory, D:\WINCE420\PUBLIC\wince project\RelDir\SAMSUNG_SMDK2410_ARMV4Release. Then in the pb working environment, find the ParameterView area, expand the tree list, find the project.bib and project.reg files, and modify them.

    Modify project.bib and add a line like A.dll $(_FLATRELEASEDIR)\A.dll NK SH.

    Copy the contents of the reg file provided by the manufacturer to project.reg.

    After completing the above, because I am using the pb4.2 environment, I clicked "make image" in the build menu. After completion, I burned the image file (nk) to the development board again. Note that I chose "make image" instead of "build platform". If you choose "build platform", it will fail, saying that it cannot find dll and other errors. The book I bought by Zhou Ligong is in the pb5.0 environment. At this step, it said that in the "build os" menu, do not select "clean before building". Then select "sysgen" to recompile and generate a new wince image.

There are two methods for physical address mapping, one is static mapping and the other is dynamic mapping. Defining the mapping relationship between physical address and virtual address in OEMAddressTable is static mapping, and mapping with VirtualCopy is dynamic mapping. Either method can be used. The one mentioned in the question is static mapping. The BSP of 2440 defines the physical start address and the corresponding virtual address of the IIC control register in the map.a file as follows:
DCD 0x91400000, 0x54000000, 1;
The virtual address range defined in OEMAddressTable is 0x8000 0000—0x9FFF FFFF. This part can be cached and is suitable for kernel programs and applications. At the same time, the WINCE kernel maps another copy in 0xA000 0000—0xBFFF FFFF, pointing to the same physical address. This part is not cacheable and is suitable for drivers. Samsung ARM processors have L1-level caches, and cacheability will improve execution efficiency. For special device registers, it is suitable to map to non-cacheable virtual addresses.
When the driver calls VirtualCopy to read and write the address 0xB1400000, WINCE automatically subtracts 0x2000 0000 from this address, which is 0x91400000. The corresponding physical address is 0x54000000, which is the physical starting address of the IIC control register.