Undefined Instruction on Blackfin BF-707 Processor

This article discusses about how we have done debugging of the Undefined Instruction Exception on Blackfin BF-707 Processor.

When debugging from CCES it is observed that the PC status is constantly showing the same address when this exception happens.

So, we tried to call the Compare Files function at the start of the function. We can see the corresponding C Code and Assembly code as shown below

Also before Undefined Instruction Exception is thrown, we can see in below picture how the disassembly code looks like

One of Analog Devices Expert suggested to keep a hardware break-point when the write happens at that address.

The hardware breakpoints can be added while debugging from the emulator.

It is available as shown in below figure

The address at which the Undefined Instruction was getting generated is from 0x080491CC

Hence we have added the Hardware Breakpoints as shown below

On this exception, when we see the CALL STACK it shows the code that is trying to alter this memory address, which is shown in below figure.

In this picture if we see the callstack on left hand side top, then it shows that TWI_Write is writing to the memory 0x080491CC. If we see all the pointers in pDevInfo in top right side one of the buffer pCommBuffer starting address is 0x0804918A. When we copy some data starting from this address, it can overwrite into 0x080491CC when the size to be copies is more than 66 bytes.

This is how we can use hardware breakpoints for finding memory area being read or written.

DCPLBMissWithoutReplacement on BF-707 & CCES 2.5.0

One of the issue that is faced on CrossCore Embedded Studio is DCPLBMissWithoutReplacement. 

We were using one of the project which is developed on CrossCore Embedded Studio 1.1.0 in CrossCore Embedded Studio 2.5.0

Then the IDE in debug mode has thrown the error which is shown in below figure

When we compile this code on CCES 2.5.0 the buffers were getting allocated at size more than 64 MB.

After we had a look at the app_cplbtab.c file which shows that the CPLB Entries are generated for DDR memory size upto 64MB. See the below screen which is taken from app_cplbtab.c

When we change system.svc file the changes shall be reflected in the files which are under system folder. The files are app_cplbtab.c, app_handler_table.c, app_heaptab.c, app_startup.s and app.ldf.

CCES provides a special syntax which the user can place in these files so that the tables can't be modified by the CCES even though the user changes in system.svc file.

When we removed the special syntax from these files the tables are updated properly and the issue got fixed

Below is the updated app_cplbtab.c

NOTE: CrossCore, Blackfin, Analog Devices and etc...are trademarks and/or registered trademarks of Analog Devices Inc

.nb0 Files

Files with NB0 extension are primarily the ROM foot print. 

We would be referring to primary bootloader for a AM335x processor. The first 4-Bytes of the image contains a jump to location address which is nothing but equals to 4K offset from the starting location.

The nb0 image also contains a ROM Signature "CECE", ROM TOC Pointer offset which is at an offset of 0x44 and ROM TOC Offset which is at a offset of 0x48.

The advantage of nb0 file is it can be downloaded to SRAM present on device and the Program Counter can be set to the starting address of the image. After wards either we can do step debugging to see which instruction is causing issues to boot the device from X-Loader and then we can trace back to the C source code.

Sleep + GetTickCount

In this article I will discuss one of the problem that I was facing with Sleep API

I had written a small piece of code which is shown below

START OF CODE

DWORD dwCnt, dwCurTick;

dwCurTick = GetTickCount();

for(dwCnt = 0; dwCnt < 100; dwCnt++)
{

    Sleep(2); 

}

RETAILMSG (1,(L"Tick Diff:%d\r\n",GetTickCount()-dwCurTick));

END

I was expecting Tick Diff:200 since we kept Sleep(2) for hundred times. But the result is seen as 300.

When we modify the code as given below
 
START OF CODE

DWORD dwCnt, dwCurTick;

for(dwCnt = 0; dwCnt < 100; dwCnt++)
{
    dwCurTick = GetTickCount();

    Sleep(2); 

    RETAILMSG (1,(L"Tick Diff:%d\r\n",GetTickCount()-dwCurTick));
}

END

Result:Tick Diff:3 is printed for hundred times.

START OF CODE

DWORD dwCnt, dwCurTick;

dwCurTick = GetTickCount();while(GetTickCount() - dwCurTick <= 200);
RETAILMSG (1,(L"Tick Diff:%d\r\n",GetTickCount()-dwCurTick));

END
Result: Tick Diff:201

So for accurate Tick Delays use the GetTickCount API.

Delay in Showing Windows Compact 7 Desktop Screen

We have created a new OS Design for our custom device.

The OS that we used is Windows Compact 7.

As part of the bring up process we are not adding all the catalog items but required catalog items only are added.

Somehow the touch driver got included and it takes almost 3 minutes to show up the Windows Compact 7 desktop. When we build a debug build it shows that TOUCH PROXY Driver is looking for something for 3 minutes.

When we add the BSP_NOTOUCH the display is shown quickly.

Some differences between Windows CE and Windows Desktop

The below table shows the some of the differences that I have thought of between Windows CE and Windows Desktop.

	Windows CE	Windows Desktop
1	Componentized OS	OS is not Componentized
2	512 MB for CE 6.0 and  3GB on Windows Compact 7	4 GB assuming 32-bit processors
3	Headless	Must have a display
4	ARM, MIPS, SH4 and x86	x86 and ARM
5	RTOS	General Purpose OS
6	1mS Timer	15.6 mS Timer
7	Not based on Foreground process	Given priority to foreground process
8	Requires very less RAM order of MB	1 GB RAM
9	Order of MHz	Order of GHz
10	Less Storage Resources	More Resources
11	One root directory	Several root directories
12	Resolution of display can't be changed	Resolution can be changed at run time