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.

CC3235MODASF: Migrating from LaunchPad to embedded processor failing

Part Number: CC3235MODASF

I am trying to reverse engineer a procedure that a former employee had set up but never documented.  All I have from the process is a .hex file that seems to program the CC3235 with a slightly modified version of the AT Command application.  With this .hex file our main processor is able to access the CC3235, reads the banner and is able to issue AT+ commands. 

We have a CC3235MODSF embedded in our product.  Programming access to program the CC3235 is via a SPI connector via a Segger J-Link jtag box.

I have gotten to the point that I can compile the AT command application and install it on a launchpad CC3235MODSF card and it appears to work fine.  I then dumped that code into a .hex file with UNIFLASH, and then use the J-LINK card to program the CC3235 on our hardware.  Everything programs and verifies, but when the software in our main card starts the CC3235 it never dumps out the banner.

I know the hardware works because the old .hex file works fine when the old hex file is programmed with the J-LINK Spi programmer..  I have to assume there is some step missing when going from the LaunchPad to the .hex file that I have not found.  Or maybe default values I need to change on the CC3235 to access our hardware vs. the Launchpad.

Here are a few questions.

Is there a baud rate setting that is part of the CC3235 UART that needs to be set in the UNIFLASH?

I noticed that there are some UART settings on the Code Composer for common.syscfg.  It seems to indicate that TXPin is 55 and RXPin is 57. These appear to be ground pins in the datasheet. Am I missing something here?  My schematic indicates we're connecting our processor to CC3235Mod pins 46(TX) and 47(RX). 

Any ideas or suggestions would be welcome.

  • We have tried that.  I added a line of code to our application that raises a GPIO pin that we have exposed, but not currently using.  It does not get raised when I load.  I will send the .hex and .dump files when I get a friend response (as I remember, that needs to be done to send private messages).

  • We have tried that.  I added a line of code to our application that raises a GPIO pin that we have exposed, but not currently using.  It does not get raised when I load.  I will send the .hex and .dump files when I get a friend response (as I remember, that needs to be done to send private messages).

  • After attempting the download you supplied, the Wifi module seemed to be bricked.  I couldn't even restore our working wifi application to it.  I even tried a factory reset, but no help.

  • Hi Wayne,

    Hmm. That's not good or what we would expect. As part of your attempts to restore, did you try a full flash format?

    I'll review the info you sent over via DM today and work on providing some additional suggestions.

    Best Regards,

    Ben M

  • Yes I did a factory reset.  I set the SOP to 000 and did a POR.  Does POR (which is poorly defined in the documentation IMHO) mean an actual power off-on, or can it be just toggling the reset pin?

     Setting SOP on our system can be a bit problematic since it is controlled by our host chip, and then only 2 pins are actually exposed.  I have a request for an ECO fixing that.

  • One question, the Launchpad (at least my LaunchPad) has a connector-of-nails port for SPI programming.  This does not appear to be the same pinouts we use with our J-Link programmer/debugger.  Is there a reference specification on what can/should be able to do this?  Different J-Tag box or J-Link cable that I don't know about?

  • Hi Wayne,

    The PoR should just be a toggle of the reset pin. By the following, do you just mean a specific cable that we expect to work here? Perhaps I can provide a picture from working with the Cheetah Programmer we have if so.

    Is there a reference specification on what can/should be able to do this?

    A couple more questions now that I was able to run back through this thread looking for clues -

    • Which UART instance are you expecting to see the terminal print-out on? (UART0 or UART1)
    • Have you always been building your new image (based on at_commands example in the SDK) in development mode?
    • Could you share the same .hex file and .dump but for the image that you have that does successfully run after reprogramming?

    Best Regards,

    Ben M

  • Also, I see there was a bit of a mix-up about the UART0 pins at the beginning of the thread. On the module package you see pins 46/47. Internally to the module, these map to pins 55/57 on the CC3235 IC. 

    These are also the pins that the bootloader uses for UART programming. If you set the SOP modes for UART programming (100), you should be able to program the module on your board via UART. You would just need to use jumper wires to connect the UART pins from the XDS110 on the LaunchPad to these pins on the module or use something like an FTDI cable.

    Not that this needs to be the solution, just a back-up idea for trying to make sure the new image is good or to potentially use to format the device if it doesn't seem to recover after formatting via SPI.


    Ben M

  • We have been using the stock at_command with a few minor changes.  It's programmed to use UART0 AFAIK:

  • Hi Wayne,

    Were you ever able to restore the device to the original working image?

    You are correct that the at_commands example uses pin 55/57 for UART which maps to the UART0 you have labeled in your schematic. That should be okay.

    Looking at the images you sent over, something that jumps out is that the original files provided (which I believe are based on the at_commands example) are much larger than the ones that seem to contain your actual application. This is strange.

    A couple additional ideas to try:

    1) I see you have the CC3235 NWP LOG pin broken out on your hardware. Could you enable this output to collect NWP logs in the at_commands example (instructions in section 20 of our programmers guide) and try to run it again? Connect the pin up to a UART-to-USB converter and see if you can log the output with a serial terminal. Let's see if we get anything when the application tries to run.

    2) Have you tried programming via the UART interface to see if the at_commands example loads and works correctly when programmed that way?

    Best Regards,

    Ben M

  • The device that got “bricked” has been replaced by a new card.

    Not sure what you mean by the file being much larger.  I show the .hex file for our working module at 741k, and the new failing module at 719k. 

    Last I looked, the NWP log pin was not outputting anything.  I’ll work on populating the new card with a UART0 and NWP connector. 

    Part of the reason we have not been able to program this wifi chip is that our “host” CPU is hardwired to the UART0 pins.  Our host software does not have the ability to do the download.  In order to use the LaunchPad (or FTDI) to do the programming requires a bit of hardware and software work, and since we can’t do the UART programming in production anyway, it’s not a solution, just a diagnostic.

    Were you able to load/diagnose our images we sent on your equipment?

  • Just soldered a connector on to our board for the CC3235_NWP_LOG.  No output from our working image.  One of our long time team members things it may have been turned off. 

  • From the documentation I see that there is code required to enable the NWP Log:
    // If your application already has UART0 configured, no need for this line
    // Mux Pin 62 to mode 1 for outputting NWP logs
    MAP_PinTypeUART(PIN_62, PIN_MODE_1);

    Not sure what this pertains to.  Is this code that should be in the wifi image? 

    I have tried setting, for example, one of the GPIO pins, both via SysCfg and via the software.  Both these methods seem to work on the LaunchPad card, but not our embedded card.

    I am attempting to load the image via UART by disabling our host and cross connecting the Launchpad card with our embedded chip's UART pins.  At this point it's been unsuccessful as the host in this config forces the SOP to 000.  Looking for ways to coerce it to 010.

  • I tried upgrading to CCS12, Uniflash8, SysConfig 1.13, and then programming with SPI, but still no signs of life in the wifi chip after writing.

  • Maybe I should regress to an older version of CCS/Uniflash?

  • Hi Wayne,

    I just got assigned with this thread. Let me 1-2 days to align on this and I'll get back to you during next week.

  • Just to clear the status... Were you able to run any code that you wrote on the device? Even a simple gpio toggling example (not adding the GPIO toggle to your AT-Command examples, just a simple program that access 1/2 gpios. you can base the simple code on the drivers/gpiointerrupt example)?

    Where you able to load it through CCS debugger (i.e. through the jtag)? to program it to flash using Uniflash over UART? to program it directly to the flash using external SPI programmer (using the hex file)?

  • You will need to add the code that sets PIN_62 to the NWP debug UART.

    These lines can be added to you application code and debug data will appear on PIN_62 as soon as you enable the NWP (i.e. after the sl_Start() call. In the gpiointerrupt example, no output is expected as the NWP is not used).

  • Our old Wifi image works fine, it's any new module that does not load.  I tried changing our new image to set an exposed GPIO pin high or low using the SysConfig settings, but that does not seem to work.  I also tried to set them programmatically, but it didn't work there either.  It looks like the new program images we generate just does not run at all. 

    Our custom card does not have the J-tag populated, just the SPI.  I'll check with our hardware people to see how hard it would be to add the connector. 

    I just tried programming our custom card Wifi by cross linking it with the LaunchPad "host".  Even though I can see the nRST and break being sent to the CC3235, it never responds to the break.  I have verified that we are setting the SOP as both 010 and 100 (both supporting the UARTLOAD), but no joy.  I have also tried resetting to the factory image but that didn't help either.

    My best guess there is that the nRst line is not within voltage spec.  We have a diode-or with our Host reset signal, so that may mung things.

  • Since we don't see any effect on our GPIO tests, I really doubt the application is really running.

  • I see this issue as one of two possibilities.  1) something in our build procedure is resulting in a busted load image, that does not even load the image, or 2) something has changed in the CCS and/or Uniflash that is generating the busted load image. 

    I've gone back through our documentation and believe that our procedure is the same as it was 2 years ago when we built our good load image.  Has there been some step added to the tools that we're missing?  Can you confirm that the current CCS/Uniflash can generate a viable .hex file for loading with SPI.  I noticed that some of the LaunchPad cards do not even have the SPI connector populated, is this capability being deprecated?

  • One idea would be to use our newly acquired XDS110 to program the CC3235.  I know it has UART pins on the aux connector, but not sure what XDS110 pin to use for nRST.  Any documentation on how to do this?  I tried Google, but nothing that looked pertinent. 

  • Regarding the old version that works - do you just have the hex file? or you are able to build it from a binary? or from sources?

    Can you try to build and program the simple gpio example from the SDK instead of your full application.

    Trying to eliminate other issues that will prevent the code from running.

  • The new version we're trying to build is from the source we believe was used in the old application.

    Did you mean SDK?  We tried loading a module that Benjamin Moore supplied, but that seemed to have the same issues. 

  • Yes, i meant from the SDK. 

    With so little debug options this is really a tough issue. I'll try to check internally what else can we offer.

  • We might have come up with a solution.  It seems that if we generate a hex file that is set to production, it loads.  I have gone the route of doing a factory reset before loading the developer version, and that didn't help.  One of our EEs suggested that it may have to do with the fact that we are setting the mac address and that developer mode does not seem to like that.  Any further information from you might help us understand this a bit better.

    Looks like things are now progressing.  Thanks for the help.

  • good catch!

    Development image cannot work for a gang image (i.e. hex file through external programmer) as it is only accepted with the specific mac address of the device in development (a mechanism that prevent using the unsecure development image in a product).