USB Speeds

Let us say as an end user you have bought a device, it has labeling like USB3.2 Gen 2 or USB3.2 Gen 1, you may be wondering what are the maximum speed supported by the device in this scenario.

The below given table lists different USB technologies with the supported speeds.

USB Technology and supported Speeds

USB Technology	Maximum Speed Supported
USB2.0 Low Speed	1.5 Mbps
USB2.0 Full Speed	12 Mbps
USB2.0 High Speed	480 Mbps
USB3.2 Gen 1 X 1	5 Gbps
USB3.2 Gen 2 X 1	10 Gbps
USB3.2 Gen 2 X 2	20 Gbps
USB4 V1	40 Gbps
USB4 V2	80 Gbps

Macros in C

Recently we were developing some source code say for feature X.

As part of the development we have written the header file something like below

#ifndef __2023_06_21_001_H__

#define __2023_06_21_001_H__

#if (CUSTOM_FEATURE_X == CUSTOM_FEATURE_VAL)

#define CUSTOM_FEATURE_X     (1u)

#define CUSTOM_FEATURE_VAL   (1u)

typedef struct

{

    unsigned int val;

}feature_x_t;

#endif

#endif /* __2023_06_21_001_H__ */

In a C source file, we have included the above header file. In C source file, we have declared a variable of type feature_x_t as following:

feature_x_t gl_feature_str;

In addition by mistake we have defined the both macro values inside the the header file itself as shown in snippet. We were wondering how the preprocessor, could find the feature_x_t variable type declaration which is being used in C source file.

After a day, what I understood is, it seems as both were not defined, #if (CUSTOM_FEATURE_X == CUSTOM_FEATURE_VAL), condition is passing, and the C Preprocessor processes the further declarations from the header file. Hence the variable type feature_x_t could be found.

CFLAGS with -Wall or -Werror in Modux Toolbox 3.0

In this post we will discuss about CFLAGS with -Wall and -Werror option in Modus Toolbox 3.0 (MTB3.0).

The user need to integrate few C source and header files. Let us assume that the filenames are source_1.c, source_2.c, source_1.h and source_2.h.

To integrate the source files into the MTB3.0 project the files were copied to the existing folder and MTB IDE could include the source files to the project automatically.

The project also contains MTB Shared library which will be generated while creating the project.

Now let us assume a function named my_function defined in source_1.c.

The user calls my_function from one of the source file present inside the mtb_shared folder. However the prototype for the function is not included into the source file which is available in mtb_shared.

As the Makefile contains CFLAGS with -Werror, the compiler stops generating the final output such as hex or bin files.

When we have added the prototype for my_function in the source file present in mtb_shared, then the IDE could generate the hex or bin files. 

The possible solutions to it are, 

1. To change the CFLAGS Setting from -Werror to -Wall.
2. Include the prototype for the functions into source files present in mtb_shared.

As removing -Werror might stop generating some other errors such as overflow calculations for example.

Hence it is advised to include the function prototypes.

USB Basics - 1

This post describes about benefits of USB

1. USB allows usage of one standard connector. No need of different types of connector like DB-9, Parallel connector. (I am talking about the older days such as 90's and still this holds good).
2. USB reduces the size of connector drastically. Compared to DB-9 and parallel connector USB connector size reduced significantly.
3. USB eliminates restarting the Host PC after installation of a driver when the connected device uses the standard drivers being used which are shipped as part Windows / Linux / Mac OS.
4. Before USB invented, to install a new hardware onto a Windows PC, one need to restart it. USB can help the device to work without restarting it. We call it as plug and play. Buy any new USB based device such as pen drive, camera, mouse, keyboard and etc... just connect them to the USB port available on Host PC, it just works like that.

Different Current ratings provided on USB Port for Charging

Universal Serial Bus in short USB is capable of providing different current ratings over VBUS.

A USB connector will have 4 basic signals called as VBUS, D+, D- and GND.

VBUS will be +5V w.r.t. the GND(Ground) signal.

D+ and D- are used for data communication between Host and Device.

For example when we connect a pen drive to the USB Port of a Host PC, the circuitry on the pen drive is powered using the VBUS and GND signals.

Then the data exchange happens over D+ and D- to see the files stored on the Pen Drive.

Now, when it comes to charging, USB is keep evolving w.r.t Data throughput and power supply.

For example these are some of the Specs from USB committee, USB 1.1, USB2.0, USB3.1, USB3.2 and USB4.

When a device is USB1.1 capable then it supports 5V@100mA.

A USB 2.0 device can support 5V@500mA. USB3.x device can support upto 5V@900mA. USB4 uses a special connector called as Type-C connector which is capable of providing upto 5V@3A

The others are 5V@1.5A and 5V@2.1A. These are called as either (CDP or DCP). When we refer CDP it means the device can charge and enumerate. When we say DCP the device can be only charged on that port and no enumeration of the device is allowed.

Flash and SRAM

 Hi,

Every embedded firmware engineer shall know a fundamental that, what goes to which area.

In this blog I will be touching two things one is Flash and SRAM.

So, what will be placed into SRAM and which part of the code written by us goes into the Flash area of MCU.

Consider below example code

unsigned int gl_Count = 0;

void get_count (void)

{

    return gl_Count;

}

void increment_count(void)

{

    gl_Count++;

}

In the above code when we declare a variable globally then that will be placed into SRAM and that is not placed into Flash. There might be some compiler constructs which might allow you to do so. However in this case there are no constructs hence the gl_Count will be allocated from SRAM.

Where as the funciton get_count and increment_count will be placed in the Flash space of the MCU.

When we implement / write a code, that will be placed in the Flash Area of the Microcontroller.  After writing the code it shall be cross compiled so that the generated output can be burned into the MCU's Flash using an external programmer / JTAG.

Hope this helps.

Read a binary file using Python

 Hi,

Today, I have to write a python script to verify the data present in it. 

We are expecting a fixed pattern from 0 to 63, until end of the file. So the snipper can be seen below.

The size of file is around 272 KB, to check if there is any value missing would be nightmare.

Hence I wrote a small python script which checks the data integrity and prints the data mismatch string on console.

import os

f = open("try.bin", 'rb')

print("Reading to buffer")

count = 0

pages = 0;

while True:

    count = 0

    buffer = f.read(64)

    if not buffer:

        break

    while(count < 64):

        if(buffer[count] != count):

            print("data mismatch")

        count = count + 1

    pages = pages + 1

    if((pages % 16) == 0):

        print("\n", end = '')

print ("No of pages", pages)

f.close()

Hope this helps for you. 

This is being tested with Python 3.7.9

Thank you for reading.

SRAM Optimization possibilities

Data Memory Optimization  for Micro controllers

 

Look at the linker map file for the items which are consuming more space.

 

Pack the structures, so that padding is removed.

 

Use bit fields wherever possible.

Use local variables as much as possible.

Do not allocate data memory as large chunks.

Try to reuse the Data memory wherever possible.  

Carefully look at the rework area after rework...!

Lead dropped on a SMD Capacitor causes short between GND and RESET Signal

One of the chip that I was working has a CAPACITOR on the RESET Signal as shown below

Now, I need to get some rework to be get done on the board. After the rework the Debugger / Programmer is not able to get access to the chip.

I have removed the debugger from the board Debug Connector.

The debug connector has 5 signals VCC, GROUND, XRES, CLOCK and DATA.

When I check the continuity between the XRES, CLOCK and DATA w.r.t. GROUND observed that XRES is shorted to GROUND. I initially thought the CAPACITOR is dead due to rework done.

But, when I checked with Hardware Engineer told me to check if there is any lead dropped on capacitor which might have caused this issue.
The capacitor is literally very small such as 0201 / 0402 package. On top of it there are wires running on the board which are unmovable due to the glue placed on the wires.


When I had a look carefully on the top of capacitor under a magnifying glass there is lead dropped on C1 Capacitor.

When the soldering technician removed the lead the debugger / programmer could get access to the Micro controller.

Thanks for reading the post and let me know your feedback...!

Root cause for the SPI Chip Select Line Going High During SPI Read and SPI Write Operation

TIMER_INTERRUPT_HANDLER

• AS shown in above figure to identify the root cause I have used two spare GPIO's SPI_WRITE and TIMER_INT
• The SPI_WRITE signal is driven low just before writing into the SPI FIFO and then the signal will be driven high after the write into SPI FIFO is completed
• Similarly the TIMER_INT GPIO is driven low when the Timer Interrupt Handler is entered and the same GPIO will be driven on exiting the Timer Interrupt Handler
• Now, one can easily understand from the timing diagram that the Timer Interrupt Handler is taking 52 uS. 
• Our SPI Clock operates at 1 MHz. The data is written to the FIFO using CPU as there is no DMA. The size of the SPI TX FIFO is 128 bytes.
• We can see that there are three bytes sent over SPI_MOSI line and then the Timer Interrupt Handler triggers and causes SPI_CS to go high.
• The SPI_CS goes high when there is no data in TX FIFO.
• So, to prevent this probably we have to figure out the best solutions like while writing to the FIFO whether we have to make it atomic, reduce the SPI Clock or write to the SPI FIFO at least 64 bytes atomically or figure out to reduce the Timer Interrupt Handler execution and so on...

Let me know your feedback on this post...!

SPI Issues Observed while testing with SPI Flash

Today I will describe one of the problem observed with SPI Flash.

The SPI Flash is connected to a PSoC4 based controller as shown below

Our write to a SPI Page is as follows

1. Write a 256-Byte Data to a given page (0x02, PA[23:16], PA[15:8], PA[7:0], D0, D1, ...., D255)
2. Check BIT0 in read status register and wait till BIT0 goes to zero. The status Register is read using the command (0x05, 0x00)
3. Now read back the data using following command (0x03, PA[23:16], PA[15:8], PA[7:0], D0, D1, ...., D255)
4. Compare the Data sent in Step.1 with Step.3. When read data is not same as written data then there is an issue either with Read or Write

Now, I thought of using a good debug tool Saleae. Attached the Analyzer to the SPI Lines.

When I check the SPI lines the chip select line goes low to high during a transfer. Hence the SPI Flash treats it as fresh new SPI Transfer.

 

As shown in above picture the green circle is the one where the SPI Transfer command started and then red circle is where the Chip Select went from low to high.

When I read the SPI Master Datasheet here it is PSoC4 based controller it says that as soon as the transmit FIFO goes empty the chip select will be driven high. When the Transmit FIFO is filled again then one can observe that the chip select going low. But, as far as for SPI Flash this is a new SPI transfer.

Now let me zoom in and show whether the chip select toggles during a read or write transfer

 

1. The MOSI Line has the following Data (0x03, 0x00, 0x13, 0x00, D0,D1, ......,D255)
2. This indicates that it's a SPI Read transaction
3. Once the chip select goes high and then low the first byte which is 0x7E is treated as SPI_Flash_Command.

The SPI Master Controller allows the Chip Select can be either hardware controller or software controlled. I quickly removed the chip select with hardware controlled option and controlling the chip select line using Firmware.

Voila!!!

The issue is not observed any more. Let me see if I can find out the root cause of the issue.

Always Read the Device Technical Reference Manual entirely

This post just talks about an experience which I have come across in 2012. It doesn't provide any other insights what are the issues faced and how they are solved.

I was working on a project where we have a reference Board Support Package (BSP) for Windows CE 6.0. So the BSP supports one of the peripheral eMMC.

The reference BSP uses a eMMC from vendor X. We have to port the eMMC driver to be functional with vendor Y .

I just assumed that after the Chip Erase the contents of the Flash will be restored to All 1's for both the eMMC devices which are from different vendors.

But, surprisingly after erasing, vendor X's ERASED_MEM_CONT shows a value of 0x01 and vendor Y's ERASED_MEM_CONT shows a value of 0x00 in the 512-byte Extended CSD Register.

So, always read the entire device technical manual.

Also the developers shall consider the availability of the technical support such as reference codes, technical manuals and etc... to be fully available while finalizing the part in the hardware.

PSoC Creator SWD Debugging Failure

This article talks about Cypress' PSoC Creator SWD Debugging error often observed by the developers.

I am using PSoC Creator 4.2 for debugging one of the Cypress' PD Controller.

So, I have opened up the project and then select Debug option from the Debug menu.

The Creator is able to program the image and then the below error is thrown

PSoC Creator SWD Debug Error.

The output window displays the below text: Error: dbg.M0015: Debugger exited unexpectedly during run.  Encountered error (Target disconnected See output window for more information.)

One reason for this could be that the SWD pins are not configured for SWD purpose and being configured in GPIO mode.

To change the SWD configuration follow the below steps

• Open the *.cydwr file to check the current configuration for the SWD pins.
• Select the System tab in the *.cydwr file.
• The reason for not able to debug that the Debug select option being set to GPIO instead of SWD.
• While choosing between GPIO's on the controllers it could be best to leave these pins so that the debugging can be performed using SWD pins.

Let me know your feedback and suggestions.

C Programming Language and for loop

C Programming language allows developers to write loops using for and while.

Consider the below C code in which for loop being used.

Code Snippet 1

In the above code the test expression uses two conditions with a comma separator.

Sometimes the developers might assume that the code in the for loop is not executed when any condition fails.But the for loop always executes when first condition is True or False and the Second condition is True. The for loop is exited when the Second condition Fails.

Hence the for loop exits when the loop value becomes 2 for the code in Code Snippet 1

Output for Code Snippet 1

Now, just interchange the two conditions and see the Result after executing the code.

Code Snippet 2

 

 

Output for Code Snippet 2

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