smartrf04eb "no em detected"

Hi,

Have you verified that it is properly installed in windows, Check [control panel]->[System]->[HW Manager]

Check for Cebal device. Maybe you need to update the Firmware on the board.

Is the board detected by SmartRF Studio?

LPRF Rocks the World

Thanks for your reply.

Updating firmaware solved the same problem when I started playing with smartrf04eb. "no em detected" didn't occur after that. But as I said one of my prototypes is working properly right now. Neither flash programmer nor SmartRF Studio is able to start communication.

antero,

How are the jumpers on the SmartRF04EB board placed? 

What is your sequence of powering up your system prior to debugging or download of code?

LPRF Rocks the World

Hi!

There are two jumpers on the smartrf04eb and they both are connected. These jumpers are next to 20pin I/O connectors. Because of testing and developing the system the main thing is to be able to debug our code. Of course the code stays in cc2430 after that and that is enough at this time. Maybe later there's going to be a need to use features of flash prpogrammer, like locking the code. But still, one of the PCBs is able to communicate with smartrf04eb. I think that tells us something. Everything should be ok, maybe. It is possible that cc2430 works fine except the debug interface. But I don't know a way to test that because I don't have logic analyzer and the procedure of starting communication between smartrf04eb and cc2430 is unknown for me, like mentioned in my first post. All I know is that RESET_N goes low and smartrf04eb sends two rising edges. I checked that with oscilloscope and it should be ok.

antero,

You say everything looks ok on the oscillocope.

Have you checked the power levels, I guess they are OK? (According to your first statement)

Have you checked the timing in details?(No violation according to the debug interface)'

Have you verified the frist command on the Debug IF?

LPRF Rocks the World

I checked with oscilloscope that the reset goes low and two clock pulses occurs. I didn't check the timing in detail. As i said earlier maybe I should have logic analyzer to verify the exact timing. It's very difficult to get closer with those kind of things with oscilloscope. Do you mean that when the first debug command is done the smartrf04eb is able to conclude if things are proceeding as they should? If I leave PC outside this system situation is same. If I connect battery to my PCB and take the usb cable off smartrf04eb shouldn't set its leds on. So is it the PC which tells the smartrf04eb to send first command or does it do it by itself, without PC connected to it?

 

By the way, what shoud the first command on the Debug IF be?

Hi antero,


The detection of the external CC2430 is performed by the firmware on the USB MCU
on the SmartRF04EB. It runs/restarts automatically when the SmartRF04EB (i.e.
the USB MCU) is powered on, no PC is required. It will do a chip detection by
trying to put the CC2430 in debug mode and try to identify the chip by the
GET_CHIP_ID debug request. If this initial detection fails and you want to
retry, the simplest way is to press the "USB MCU Reset" button on the
SmartRF04EB.

If you sniff the DD/DC/Reset_N lines for the debug interface, you'll see the
CC2430 chip detection as:

1. enters debug mode (Reset_N goes low, to rising edges on DC, and Reset_N goes back high)

2. send in 0x55 0x00 (debug command: DEBUG_INSTR NOP) for the CC2430 to perform
a NOP instruction and read out a 0x00 (value of ACC register) [just a test]

3. send in 0x68 (debug command: GET_CHIP_ID) and check if it returns 0x85 0xNN
(CHIPID CHVER registers) to decide if it's a CC2430.

(NB: you asked about what happens before this; it will try to detect other
supported chips, i.e. CC1100/CC1101/CC2500 transceivers over SPI), so you may
see the Reset_N

No PC tools will work or be able to communicate with the chip (CC2430) if the EB
says it didn't detect anything, so this will have to be successful.


Troubleshooting tips:

¤ You said you already had done a firmware upgrade, so I guess your firmware is
up to date. (Just to confirm, the firmware with ID=0x0400, revision=0x0036 or
newer revision is recommended. You can check the revision (and update if needed)
by using the Flash Programmer PC application (
http://www.ti.com/litv/zip/swrc044e ) or latest version of SmartRF Studio.)

¤ If you have a CC2430EM, verify that it gets recognized properly when you use
the EM socket.

¤ You said you used the SOC_DEM, and a cable to your external prototype. Make
sure the target is powered when the chip detection is performed. Make sure you
have connected SOC_DEM's pin 2 to your prototype's Vcc. As you correctly said,
this is required by the voltage level converter on the SOC_DEM.

¤ Do you use the original 10-pin flat cable (approx 30 cm) or do you have your
own custom cable? If the wires from the SOC_DEM to the target board are too long, the
detection may fail due to timing errors/signal distortion.

¤ You mentioned you powered your target board via the SmartRF04EB. Can you try
to power it separately? Maybe (somehow) the detection happens to quickly before
the target board is properly powered, causing it to fail. Or try the "Reset USB
MCU" button instead of cycling EB power on/off. If you power it from the
SmartRF04EB (3.3V), can you verify that your PCB is receiving the proper voltage
level?

Thanks "stole my lunch?" for your inclusive reply!

About your tips:

* I tried updating firmware by downloading the newest flash programmer --> no help

* CC2430EM is recognized as it should

* Target gets its VCC + gnd. SOC_DEM's pin2 is connected to VCC. I have checked every wire many times. I have also repeated this by making two extra cables. --> no help (The working prototype works with everyone of these cables )

* The cable I'm using is 10-pin flat cable + my own wires connected to it. DC,DD and RESET goes straight to the PCB. VCC + GND are connected also to PORT0 (3.3V and GND). Wiring has been like this all the time when debugging. The prototype works also with battery, "no em detected" occurs then also. The cable looks doubtful because it is made myself. But the fact is that it is ok because it works with one of my prototypes. The debug connector in proto is only  five pads. I have thought that maybe solvering process causes too high temperature and therefore problems. But I have concluded that it's not the reason because after this "no em detected" occured first time, I tried with another PCB ( it had been working earlier ) and the same text appeared on the screen. No solvering was done before this.

* I have also tried using "Reset USB MCU" --> no help. When using 3.3V the level on the PCB is 3,26 V, and that should be enough.

But I have to check this "procedure of starting to debug" again. I have done it but now I know what the bits should be ( I know that the bits aren't what they should be ). First of all with working PCB the DD is low at the beginning. With "broken" PCB ( the code starts to run when powered up with battery ) DD is high at the beginning. I'm going to get those bits not until tomorrow.

Maybe something has destroyed cc2430s' debug circuits (according to cc2430 block diagram in data sheet). If it is impossible to get connection to the cc2430s I must start to figure out what is the cause of this problem.

But thanks again for your great reply!

Hi,

I encountered a similar problem as you described. I tried to program a few self made boards which followed CC2430DB reference design. Some boards work but others have this "No EM detected" problem.

Here is how I eliminated other possible causes:

(1) not a firmware problem: as SmartRF04EB can program some of the boards.

(2) not a VDD or GND connection problem. I tested all GND and VDD pins. They are OK.

(3) not SOC_DEBUG connector problem. GND, VDD, DD, DC and RESET_N are all connected to CC2430's corresponding pins.

I used Saleae logic analyzer to see the difference of DC, DD and RESET_N between the working cases and the non-working cases. I attached the screenshots here.

Working case:

Non-working case:

I see two main differences. One DD in the non-working case remains High when no messages are sent between CC2430 and SmartRF04EB. The other is that RESET_N has an additional RESET in the end, which might cause the CC2430 to reset its state.

What makes the difference? I do not think the chip is damaged in the DC/DD part. I had three boards like this. They all produce the same DC/DD patterns described in the non-working screenshots.

Thanks for any thoughts and suggestions.

regards,

Yuan Jian

Hello, this is a very interesting thread. Let me put forward my scenario.

We are using CC2530 and built out custom made boards. When we connect these custom made target boards to the SmartRF05EB 1.8.1, we are getting the message "No EM Detected". The target board is connected with individual wired jumpers to the External SoC Debug connector (P3) of the SmartRF05 EB. The Target Board is separately Battery Powered. I am explaining the connections below.

1. DD is connected

2. DC is connected

3. RST is connected

4. VCC is extended from the Target Board to the SoC Debug Connector P3 - Pin 2

5. Grounds Connected between the Ext SoC P3 - Ground and Target Board Ground

In the process of finding out the reason and solution to the same we connected using the same individual wires a Good and Working standard EM that comes with the SmartRF05 EB and connected as above. And we got the same result - "No EM Detected". It looked strange as this standard EM when sits on P5 and P6 of the EB works fine and we have successfully put our Application Program there. So what could be the case for the Good and Working EM not being detected by the SmartRF05EB when of course it is connected using the External SoC Debug.

May be good to mention here that the Standard EM when connected in this way is NOT running the Application Program and when we disconnected the RST wire (between the ExtSoC P3 and Target Board) the Application Program is running Fine. May be this will help. 

The Firmwire is version good. EB FirmWire Id = 0500 and EB FirmWire Rev 42/43. We have tried the same set up in both our SmartRF05 EB but the same result.

To a great extent I have gone through previous posts on similar topic but no much help till now.

Request you to please help us.

Kind Regards,

Sibasish

Hi Sibasish.

Based on your description, it seems like you have done most things correct when setting up the connection between the SmartRF05EB and your external CC2530 custom boards.

A typical error is to forget to connect pin 2 (=Vdd from external target board) on the External SoC debug connector (see figure 15 in SmartRF05EB User's Guide -- http://www.ti.com/lit/pdf/swru210 ) when the target board is separately powered, but you have correctly remembered this. (This is needed for the voltage level converter on the SmartRF05EB to sense which voltage level it should use on the signals interfacing the external target board.)

You say you have connected the grounds between Ext SoC P3 and the target board. Did you use pin 1 (=GND) for this, or perhaps pin 9? Please try pin 1, if you haven't already.

Regards,

esy