TIOmap37xx series MPU debug SE4500 scanning head 2D scanning soft solution records

Although Motorola has also sold it to banma, there are few articles on debugging SE4500 on the TIOmap platform online, if you do not believe it, search for the Internet. The company uses the Omap37xx series Mpu solution provided by TI (Texas Instruments). The system is developed by WM6.5 (WindowsMobile6.5.3) for debugging.

Although Motorola has also sold it to banma, there are few articles on debugging SE4500 on the ti Omap platform, if you do not believe it, search for the Internet. The company uses the Omap37xx series Mpu solution provided by TI (Texas Instruments), the system is WM6.5 (Windows Mobile 6.5.3), debugging

Although Motorola has also sold it to banma, there are few articles on debugging SE4500 on the ti Omap platform, if you do not believe it, search for the Internet.

The company uses the Omap37xx series Mpu solution provided by TI (Texas Instruments). The system is WM6.5 (Windows Mobile 6.5.3). the I2C problem started when the system was debugged to SE4500, i2C failed. Later, the I2C read/write problem was solved. However, when the corresponding API was called at the upper application layer to obtain image data, the system crashed, but the address was printed out, you can still see the corresponding address, but after testing the pointer using IsBadPtr, it cannot be read, as long as one read, it will crash directly (data abort ).

The problem is that you need to modify part of the code of the driver provided by Motorola. The modifications are basically as follows:

Add the readme.txt operation in the driver directory according to Motorola \ Motorola Software Decode SDK for ARM \ Drivers \ TI \ cam_SE4500 \ WM65,

In the CAM_IOControl () function of the corresponding drvr_intf.cpp source file, the specific modification is as follows:

Case SE45_IOCTL_ALLOC_BUFFER: if (pBufOut = NULL) | (dwLenOut <(sizeof (SE45_ALLOC_BUF_REQ) + (pDev-> dwBufferCount-1) * sizeof (DWORD ))) | (Signature = NULL) {dwReturn = signature; goto BadParameter;} else {UINT I, nOutputByteCount; inclupallocreq; HANDLE hCaller; PBYTE pVirtAddr; // wince5.0.2 kernel restrictions, therefore, you must add this judgment # if (_ WINCEOSVER <600) BOOL bOldMode = SetKMode (TRUE); # endifnOutput ByteCount = sizeof (SE45_ALLOC_BUF_REQ) + (pDev-> dwBufferCount-1) * sizeof (DWORD); # if (CE_VERSION = 5) // hCaller = GetOwnerProcess (); // Why Do I Need To comment out the above line of code and change it to the following line? Because at the same time, they should be the same process address space hCaller = GetCurrentProcess (); pAllocReq = (rj45_alloc_buf_req) MapCallerPtr (pBufOut, nOutputByteCount ); # endif # if (CE_VERSION = 6) | (CE_VERSION = 7) // hCaller = OpenProcess (0, FALSE, GetCallerVMProcessId ()); hCaller = OpenProcess (0, FALSE, GetDirectCallerProcessId (); // CE 6 automatically als the IOCTL parameters mapCallerPtr () is obsoletepAllocReq = (rj45_alloc_buf_req) pBufOut; # endifif (NULL = pAllocReq) {dwReturn = ERROR_INVALID_PARAMETER; goto BadParameter;} // Reset the user buffers in the low level drivercamera_reset_buffers (pDev ); pAllocReq-> nNumBuffers = pDev-> dwBufferCount; pAllocReq-> nBufferSize = pDev-> dwBufferSize; // Save the caller handlerpDev-> dstProcess = hCaller; /* return a list of buffer start addresses mapped to caller's process space */for (I = 0; I <pDev-> dwBufferCount; I ++) {if (camera_get_buffer_addr (pDev, I, & p0000addr) {# if (CE_VERSION = 5) pAllocReq-> ppBuffers [I] = (DWORD) MapPtrToProcess (p0000addr, hCaller ); # endif # if (CE_VERSION = 6) | (CE_VERSION = 7) pAllocReq-> ppBuffers [I] = (DWORD) VirtualAllocCopyEx (GetCurrentProcess (), hCaller, pVirtAddr, pDev-> dwBufferSize, PAGE_READWRITE ); # endif // Save it in the driver context for freeing this memory laterpDev-> baseAddr [I] = pAllocReq-> ppBuffers [I];} else {pVirtAddr = NULL; pAllocReq-> ppBuffers [I] = (DWORD) NULL;} DEBUGMSG (ZONE_IOCTL, (TEXT ("SE4500: App: 0x % x mapped from Kernel: 0x % x \ r \ n "), pAllocReq-> ppBuffers [I], p0000addr);} * pdwActualOut = sizeof (DWORD) * (pDev-> dwBufferCount-1) + sizeof (SE45_ALLOC_BUF_REQ); # if (_ WINCEOSVER <600) SetKMode (bOldMode); # endif} break; case SE45_IOCTL_GET_CURRENT_BUFFER: if (pBufOut = NULL) | (dwLenOut <sizeof (UINT) | (pdwActualOut = NULL) {dwReturn = ERROR_INVALID_PARAMETER; goto BadParameter;} else {// wince5.0.2 kernel restrictions, therefore, you must add this judgment # if (_ WINCEOSVER <600) BOOL bOldMode = SetKMode (TRUE); # endif _ try {if (camera_get_buffer (pDev, (PUINT) pBufOut )) {* pdwActualOut = sizeof (UINT);} else {dwReturn = Hangzhou; goto BadParameter ;}__ except T (prediction_filter (GetExceptionCode (), GetExceptionInformation () {DEBUGMSG (ZONE_ERROR, (TEXT ("Exception in IOCTL_GET_CURRENT_BUFFER \ r \ n") ;}# if (_ WINCEOSVER <600) SetKMode (bOldMode); # endif}

Later, we thought about directly saving the obtained image to a file in the system driver. There seems to be a problem. The file storage operation was done in a separate thread, it is an asynchronous operation and may save only part of the data. After multiple tests, the resolution of the transmitted image 752x480 is always striped, or the color is incorrect, basically like:
     


These images are saved in the callback function for driving image frames. Basically, there are only one or two images in more than 30 images. The other images are essentially oblique stripes, and the color is obviously incorrect, the normal color is black and white monochrome. Later, I checked the hardware and found that the maximum frequency of support for the PCLK level conversion chip was not enough. Like other companies, if you use TI's solution, what PMIC should you use, the level conversion chip and so on are all used by Qualcomm and MTK.
We used TXS0104/08 to convert the 3.3V level from PCLK of SE4500 to 1.8V for Omap37xx, it is found that the maximum data rate supported by TXS0104/08 when Vcca is 1.8V is only 24 Mbps (refer to the level conversion chip Manual), which is far from enough.
After several months, I did not solve this problem. Later I switched to the TXB0104/08 Series level conversion chip and used the SDL_GUI test program written in C # provided by the motorcycle, after the SE4500 light is sent, It is decoded directly.
So far, the problem has been solved, but to sum up one point. TI does not need high data rates for most application scenarios. It is only simple level conversion. However, for video transmission, the selection of level conversion chips is particularly important, if the speed is incorrect, the transmitted data may be wrong. When selecting a chip, you must fully consider its application scenarios.