This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am experiencing verification errors on a design refresh (303), based on an existing functional design (302). The Erase, Erase and Write functions have worked with mixed results across various Windows installations, and SmartRF04EBs. Any read-back or verification of flash fails. We've used the latest Flash Programmer and SmartRF Studio with SmartRF04EB to communicate with the device.
The layout pays close attention to the CC2538_CC2592 EM design for relevant chip spacing and layout details.
From existing TI posts on the topic, DD+DC signal integrity and 32 MHz crystal timing appear to be prevalent causes.
I have included oscilloscope captures of the flash write DD+DC lines, and 32 MHz crystal on the latest design and existing known-good design. I used a passive 10x, 300 MHz probe on all measurements with the DUT powered by laptop battery through SmartRF04EB.
I have layout CAD and other materials for evaluation, where useful.
302 crystal:
303 crystal:
303 DD+DC:
Hi,
On the bad boards, with the same setup, are you able to flash any other hex file e.g. anything pre-built from ZigBee examples for CC2530 from TI website?
regards
On the new design, only a basic IO toggle image flashes successfully. The light_switch and all other images tried, flash successfully on the existing functional design.
I've measured against and confirmed:
DCOUP 1.89 Vdc - with mV ripple
VDDS, VDDR lines 3.5 Vdc nominal from the SmartRF04EB
Idle current consumption is in line with datasheet, it appears the 32M oscillator may not be starting.
Hi,
You mentioned that light_switch example flashes successfully, does it work as well?
Did you see the xtal start when you flashed the image on 303?
Can you share the hex file?
regards