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.

CC2541 not advertising when flash configured via debug port

Other Parts Discussed in Thread: CC2541

hi there,

 I have a hex file built by IAR embedded workbench that , when used with CC debugger, correctly configures the CC2541 with a program that starts GAP advertising from after reset. It also has an active serial line handler. When configuring the device on our system board with my own flash loader (program running on ARM processor connected by GPIO lined to DD,DC,RESET_N as well as TX/RX UART), I can get the CC2541 to run and can monitor its state via the serial line debug messages I am putting out -- I can see it say it is starting advertising and I see when it stops. However I am not seeing any advertisements from my other devices. In the past when I have had this issue, it has been due to the wrong CC254X stack  library being loaded as well as a wrong crystal frequency on our radio board. This does not seem to be the case right now, both are correct. And I can get it to advertise if I flywire the CC debugger to the debug lines.  Are there any other reasons this could occur?  Anything I have to do in my flash loader program to ensure the radio runs correctly?

 thanks!

  -Tyler

  • hi Tyler,

    Nothing I can think of. The  SW is all in flash, except for a portion of the radio, which you can't erase.  If you can switch to debugger after flashing, then perhaps use "debug without downloading" to step into code with IAR. Seems you are running. Maybe check power with scope to see if there is any increase during an advertisement.

    BR,

    -Greg

  • Hi Greg,

     I think it is the external 32 kHz XOSC clock again(first spin of our radio board had the wrong crystal on it). I inspected CLKCONSTA and bit 7 never gets set after I set CLKCONCMD  (via the debug port) or the program (in normal boot after reset) .  I will put a scope on it Tuesday to see if the crystal is behaving as expected. Could be a power supply issue as well. 

  • external clock seems fine. No clue what could be causing this. 

  • hmm... so what I was doing was creating a 128K memory image on the host, initialized to zero, and fill in sectors from the hex file, and then DMAing to the 2541 in 2K chunks. I changed the memset to 0xFF...and it suddenly works. Why? 

  • Flash memory is "erased" to 0xFF. So setting 0 looks like data was written from the chip's perspective

    My hypothesis is that your program calls oasl_snv_inti() at some point.  Osal_svn can detect when there isn't enough free (0xff) flash memory and it tries to compress the data. Since all of the memory is "written" to, the compression will hang and forever try to free up the memory it needs.

    How did you fix the issue with the DMA read/writes? Also, what's up with that font?

  • Hi Peter, it has to be something like that. 0xFF is the erased value so something is expecting that. oasl_snv_init is a good suspect. 

    DMA is working, I found a bug in the DMA descriptor /buffer init that I got from the TI sample code, it only had 512 bytes and the descriptors would be overrun on the first DMA if the DMA from debug was longer than 512. That explains the partially right first page and zeros afterwards that I was getting.   I think there was also an address aliasing issue so you have to be careful with the address masks.  read back works but you have to be careful about the bank select masking/windowing.