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