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
Other Parts Discussed in Thread: CC3235MODSF, SEGGER, UNIFLASH, SYSCONFIG, CC3235SF, LAUNCHXL-CC3235SF, LAUNCHCC3235MOD,

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.

  • Hi Wayne,

    The UART Configuration of the device is shown below: 

    When you flash the device, it must be in Bootloader mode. Inside the ROM for bootloader mode, the UART configuration defaults to these settings and cannot be changed. 

    For your question about Sysconfig, the sysconfig tool will default to a single pinmux (which specifies pins 55 and 57 as UART TX/RX). The device does support pinmuxing pins 46 and 47 to UART TX and RX, but these must be specified within sysconfig or within the configuration files before flashing. 

    Best,

    -Ryan

  • I am successfully able to flash the device and readback the EEPROM, so that's not the problem.  What I want to know is when the application starts, what sets the UART baud rate.  There are configuration settings for the UART in sysconfig, but these don't appear to include baudrate.  Where would I set the CC3235 UART baud rate. Our current CC3235 app appears to be talking to our host CPU (a NXP Arm m4 device) at 115200.  What in the new CC3235 app needs to change to talk at this speed?

    Any pointers to documentation that talks about converting from LaunchPad to an embedded CC3235?  Also, I'm not finding any detailed info on SysConfig for a 3235.  Any suggested reading?

  • Hi Wayne,

    I would recommend taking a look at 2.4.2.1 in the NWP Programmers Guide, Linked in this E2E thread: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/704632/cc3220sf-launchxl-swru455e-network-processor-programmer-s-guide-404-not-found

    This provides an example for how to dynamically change the baud rate of UART on the device. There is not much existing documentation on sysconfig for specific devices (like the 3235), but we are working to address that issue. 

    Best,

    -Ryan

  • OK, so uart_term.c defaults to 115200 baud, which is what we are expecting.  What other changes do we need to make when going from LaunchPad (which works great) to a custom board.  I reiterate, that the hardware had proven to work, just not the new software app.

  • Hi Wayne,

    Thanks for the clarification there--What I'm thinking is happening is that the pins you are specifying in your schematic do not line up to the pins that are specified in the project sysconfig file--Meaning the project hasn't been updated to use pins 46/47 instead of 55/57.

    Using the at_commands example project, I'm working through trying to make the modification for allowing a UART connection to pins 46/47 for TX/RX. If you are able to specify these pins successfully, let me know.

    Otherwise, I will update the thread soon with my status.

    Best,

    -Ryan

  • I believe I have the right pins for the right UART now, but still no joy. 


    But that doesn't match what's in ti_drivers_config.c.  But maybe that's because I'm using the 3235modSF.  That was one of the changes I made when going from the launchpad to the embedded. 

    Reviewing the schematic shows they used pins 46 & 47 as well. I probed those pins and see 3v3, one of my next steps is to solder in a header to expose those signals to put it on a FTDI and see if there is indeed any characters flying out that my DVM and scope might have missed.

  • Hi Wayne, 

    I'm seeing the same behavior on my side as well--even when changing the TX and RX pins in the sysconfig tool GUI, they are not updated in ti_drivers_config.c. 

    If you are able, please let me know what you are able to find by physically probing these pins on the device. In the mean time, I will reach out to other team members internally to see what the issue inside sysconfig may be. 

    Best,

    -Ryan

  • Not seeing anything come out pin 46.  Just shows 3v3 hard.  Not even garbage as would happen with a baud rate issue.

    I tried configuring UART1 to see if anything changed on pin 48 & 49.  But the hex file is the same size.  I would assume that the additional structure in ti_drivers_config.c would increase the size.  I would also have expected the UART1 pins go from HiZ to 3V3. 

    I wonder if my configuration is actually making it to the .hex file I am programming on the flash.  What do you use as a process going from the CCS build to the flash?  

    BTW, thanks for all the help.

  • Quick question for you, Wayne--are you using a 'UART' or 'UART2' instance in the Sysconfig GUI:

    I would recommend using UART2 instances if you are not. They use the same peripherals and pins, but UART2 has an updated driver that is described in the API documentation.

    Best,

    -Ryan

  • Good idea, I'll try that.  Thanks.

  • Tried that, but I'm getting an unusual undefine error:

    makefile:177: recipe for target 'at_commands_CC3235SF_LAUNCHXL_tirtos_ccs.out' failed
      symbol         in file                                                                                
     ---------   ----------------                                                                           
     UART_config C:/ti/simplelink_cc32xx_sdk_4_10_00_07/source/ti/drivers/lib/drivers_cc32xx.aem4<UART.oem4>
     UART_count  C:/ti/simplelink_cc32xx_sdk_4_10_00_07/source/ti/drivers/lib/drivers_cc32xx.aem4<UART.oem4>
     
    error #10234-D: unresolved symbols remain
    error #10010: errors encountered during linking; "at_commands_CC3235SF_LAUNCHXL_tirtos_ccs.out" not built
    gmake[1]: *** [at_commands_CC3235SF_LAUNCHXL_tirtos_ccs.out] Error 1
    gmake: *** [all] Error 2

    Is it possible that 4_10_00_07 does not support UART2?  I also had to change the name of the UART from CONFIG_UART2_0 to CONFIG_UART_0.

    I was sticking with 4_10_00_07 because that is what the original package was written with.

  • Hi Wayne,

    It is possible that the older version does not support UART2. Have you tried updating your SDK version? The most recent version (6.10.00.05) has small bug fixes and updates to the UART2 driver, and it's available here

    Best,

    -Ryan

  • After thing about it through the weekend I decided I need to prove that the application I am downloading to the CC3235 is indeed working at all. 

    Supposition: Is the application I am programming on the wifi chip actually running. Test: Add code to the Wifi chip application to raise GPIO09. This signal is currently unused, and exposed on our card. When I load this mutant wifi app on the LaunchPad, I do indeed see the pin go up. When I run it on our hardware I do not. This proves my supposition that the app is NOT running. Right?

    So back to my initial question for this thread, what steps do I need to take to prepare a launchpad based application to run on custom hardware via SPI?  Currently I take the at_commands_CC3235SF_LAUNCHXL_tirtos_ccs.bin and run it through Image Creator using the Development Mode - Generate Image page, Create Image button, then the Save Hex button.  I then program the CC3235 via the Flash SPI interface.

    The part I really do not understand is that the UniFlash program does not have an option for creating the SPI hex file directly.  It requires that I select the CC3235SF Serial configuration.  Is there some other way to create the SPI hex file that I am missing?

  • Hi Wayne,

    Great idea with the debugging steps you tried earlier--thanks for checking this. 

    You can create the Image Hex file through: Uniflash -> image creator -> burn -> save hex! 

    I'm not sure where the serial configuration is needed in this process, however. 

    Just to make sure--you are using Image Creator and not using Uniflash to program the device directly, right? This can cause issues.

    Best,

    -Ryan

  • When I start Uniflash, it tried to detect my LaunchPad (via USB).  Probably not what I want if I want to program the embedded CC3235 so I leave it to manual.  I can then "Choose A Device" or "Create Session From Existing Target Configuration File". 

    In this case under Choose Your Device, I can select either LAUNCHXL-CC3235SF or CC3235SF(BOOTLOADER).  I'm guessing the second is the correct choice since here again, I don't want the LAUNCHXL-CC3235SF:

    But I only get buttons to Start or Edit.  These lead to a Select and Load Images page:

    It appears to be requiring a .SLI file but I have no idea where that comes from.  It is also wanting to talk on COM1, but since my embedded CC3235 is going to be programmed by SPI, not UART this is wrong too.

    So I go back to the New Configuration page and load LAUNCHXL-CC3235SF.  This now asks if I want to start the Image Creator, but is again implying that I will be accessing the Serial UART interface. 


    I set up the MCU Img, Service Pack, and Radio settings:

    mcuflashing.bin has been selected from the output from the CCS build:

    I then click Burn, Create Image, and Save HEX:

    I then burn that hex file to the Wifi Flash.  But the AT_CMD app does not come up.

  • I have tried sp_4.13.0.2_3.7.0.1_3.1.0.26.bin, but that didn't help.

  • Hi Wayne, 

    After looking at the Uniflash ImageCreator User's Guide, you may not be able to use the ImageCreator tool to program the device in this way:

    I'm reaching out to more teams internally to gather information and next steps.

    Best,

    -Ryan

  • But isn't what we're doing what is listed in the second bullet listed?  Using an external off-the-shelf tool to program the serial flash?

  • Hi Wayne, 

    Can you describe the process you are using to burn the hex output to the WiFi Flash?

    Best,

    -Ryan

  • We have exposed the Flash SPI pins to a Tag-Connect connector and then to a Segger J-Link SPI programmer.  Mind you, this processes (burning the flash) works for our old undocumented Wifi package.  Unfortunately the person who did the package is no longer with the company.  My job has been to try and reverse engineer the process.  All I inherited is the slightly modified AT_Command source in a CCS project.  Programming this source in the LaunchPad works fine.  So the problem has to be with my procedure to convert the CCS .bin file to be a .hex file to be programmed into the flash.  The file (old working) and new (not working) look somewhat similar when I diff them, and are only 11k in length different.

    Anyway to disassemble the .hex file beyond the Intel Hex formatting? 

  • Hi Wayne,

    Thank you for the background on this project and your involvement in it--I understand the issues at hand. There doesn't seem to be any glaring issue with the method you are using for flashing the device. 

    That being said, TI does not support disassembly of the .hex file created by ImageCreator.

    Best,

    -Ryan

  • Hi Wayne, 

    Apologies for the delay. I will ping the thread soon with next steps.

    Best,

    -Ryan

  • Any update?

  • Hi Wayne, 

    Apologies on the delay--We've been working internally to try and find the best solution for this. 

    Have you tried programming the launchpad for the CC3235 using the J-Link device? If there is an issue in programming the device using SPI then we can isolate the issue to the format of the output of the hex file. 

    One other thing I can try is to do a "beyond compare" comparison of the two hex files--one from an older service pack that should be working and from yours. There may be some headers or differing frames causing mayhem.

    Best,

    -Ryan

  • I have attempted SPI programming with the J-Link using J14 on the 3235ModSF Launchpad.  It reports that the target system has no power.  I'm a bit suspicious since J14 is marked as DNP on the Launchpad schematic and not shown at all on the Assembly Drawing.

    Both new and old releases of our AT Command program do run on the LaunchPad when being programmed via CCS or Uniflash. 

    I can send you both the .hex files, but would prefer not to send them in public.  Is there a private file server somewhere I can send them to?

  • Hi Wayne,

    How are you connecting the SPI Debugger? I don't see J14 as DNP on my end--can you show me how you're connecting to the device?

    Best,

    -Ryan

  • I am connecting the J-Link plus, through a TC2050-ARM2010 to a TC2050-IDC-NL.  Guess I assumed that since the plug fit, that's where it should go. 

    Looking at the SPI bus, it does not show Vcc.  Just MOSI, MISO, CLK and CS. 

  • Hi Wayne, 

    Do you know what revision of the launchpad board you are using for this project? On my board I see that portion named differently and with different components soldered around it..

    I'm comparing the two versions of the hex files now.

    Best,

    -Ryan

  • Looks like LAUNCHCC3235MOD PCB Rev A.  No other markings or labels except for a QR code on the back with 1537243.  Serial Number?

  • Hi Wayne, 

    I'm looking with a product expert now to check the headers of the two project .hex files and to verify the launchpad questions--I should be able to respond by EoD for this. 

    -Ryan

  • Hi Wayne, 

    Taking a closer look at the hardware you are using, does the debugger you are using (the TC2050-ARM2010) support SPI programming? I see that it has output for JTAG and SWD, but I don't see that it supports SPI programming. 

    Best,

    -Ryan

  • It appears to have.  The J-LINK Plus manual shows the pins as:

    The TC2050-ARM2010 then configures the signals out to a C2050-IDC Plug-of-Nails Cable that connects to our custom board.  This must work since we are able to program the older release .hex file. 

    Question for you...  The XDS110 debugger, does it do SPI?  I have been unable to get it to connect to our cc3235 with the famous (Error -1170 @ 0x0) Unable to access the DAP.  The most likely scenario would be the Developer mode is not set.  Looks like on the LAUNCHPAD the chip is programmed via UART.

  • So I went back to my build process on CCS.  Trying to compare our build process to the at_commands example.  First thing I noticed is that the project properties are quite different.  Left is our build project, right is the at_commands example:

    Note the Configuration and tab names.  Is it possible that our version's project was created with an older version of CCS, and that CCS does not update the project information?

    Now look at the directory structure:

    Here the old code uses the common Eclipse output directory Debug.  On the new at_commands example we have a MCU+Image output directory and a config file image.syscfg.  Could this mean that the .hex file I am generating from the old code is a simple application image, but the new at_commands example is generating a whole lot more, including things like a .sli file etc.  I'm going to try and rebuild the .project and other files in our old code and see if I can import it to the new layout.

  • Hi Wayne,

    Thanks for the updates--unfortunately the xds110 is only for JTAG debugging--not for SPI. 

    As for the Error message you are receiving--this most likely comes from jumpers on the board connecting the CC3235MOD side to the Debugger side of the board--can you verify using the User's Guide that you have connected the jumpers correctly for JTAG?

    Its a great idea to restart the process of building the projects--please keep me updated to see if there are any issues we can tackle.

    Best,

    -Ryan

  • I have SOP set to 000 at reset. As I read the doc:

    Functional development mode. In this mode, 4-pin JTAG is available to the developer. TDI, TMS, TCK, and TDO are available for debugger connection.

    I have rebuilt the project from the at_command sample, but not had any luck yet. 

  • Hi Wayne, 

    Thanks for the update. Given that there are issues when trying to program from SPI on the Launchpad, I'm concerned that the method we're using to flash the device is the root cause, and not the project .hex file itself--just a hunch. I'm talking with more members of the team today and will advise this afternoon. 

    Best,

    -Ryan

  • Hi Wayne,

    Are you holding the device in Reset while attempting to program via SPI? Without doing this, there will be conflicts with 2 masters connected to the device. 

    Additionally, let's isolate the issue to one thing. You have said that you're able to program the Launchpad via CCS/UART, correct? After doing this, are you able to use an external SPI read/write tool to get a dump of what is programmed in serial flash? Ideally, I'd like to compare the dump of what you're seeing in serial flash when programming via SPI vs programming using UART/CCS.

    Best,

    -Ryan

  • We are holding reset down while doing the SPI write.  In fact, the previous developer has all the J-Link probes modified to hold it at reset for some reason.  We have to unplug the cable to get it to boot.

    We do not have the ability to program the flash via UART on our custom board.  We would have to write an interface in our own code to do that and that is a considerable task at this point.  I have been thinking that I can set up our new XDS110 to do a UART download via the aux port (like I assume the LaunchPad does).  This has been low on the priority list since doing this in production would be difficult. 

    I have not been able to use the SPI on the Launchpad.  The J-LINK SPI ports appear to have a different pin-out on the connector-of-nails port than what we use. As there appears to be no other access to the LaunchPad SPI I'll have to figure out some sort of breakout between the LaunchPad and J-Link.  Since there appear to be different versions of LaunchPad circuits out there, how confident are we that my LaunchPad matches the current schematic?

  • Hey Wayne,

    Ryan is currently out of office and will be back later this week. I will take a look to see if I can provide feedback here, but wanted to provide you an update on the delay.

    Best regards,

    Jesse

  • Thanks.  We're pretty much stuck at this point. 

  • Hi Wayne, 

    Apologies for the absence here. 

    My thought is to first program the Launchpad via UART through CCS--as is normal. Then we can read the data from the Serial Flash on the device. After this, you can try to program the Launchpad again via SPI (which I understand is failing) and then compare the Serial flash on the device in this case to the Serial flash from the UART flashing. (Let me know if I need to be more clear in describing this).

    When we can get the SPI programming to work on our device, we can be more confident that we will be able to flash your device with SPI. 

    With that being said, do you have a way to read the Serial Flash after it has been programmed?

    With your version of the launchpad as well, we are confident that you will be able to program via SPI--We have been able to create a working version of this previously using a Cheetah SPI debugger.

    Best,

    -Ryan

  • Sorry for the delay, my boss had me fighting other fires.  In order to do this, I will need to create a special Connector-of-nails cable to connect to the launchpad to do SPI programming.  The launchpad connector-of-nails plug has a different pinout then what we have on our custom card.  Not sure which is right.  This may take a while.

    We've also learned that we will need to reprogram all our systems due to the fact that GCP (Google Cloud) will be discontinued next year.  This will invalidate all our security certs and require reprogramming the Wifi.  The race is on.  Up till now it's simply been a race to replace missing knowledge. 

    Any ideas as to why the SPI programming it isn't working?  I sent you a load module, did you get this to work? 

  • Any further information?

  • Hi Wayne,

    Ryan has moved to another team so I will tack this thread moving forward and pull in other members of my team to support if needed.

    Let me recap on all the details here since there has been a lot of back and forth. Let me know if any of my understanding of what has been discussed up to this point is not accurate -

    • You use a process for programming the CC3235MODASF in your design based on a direct SPI programming of the SFLASH embedded in the module
    • You use a J-Link product with SPI programming capabilities as the tool to write (and maybe read) from the SFLASH
    • You have an original application image (including the MCU binary, device config, and additional files like certificates maybe) that can be successfully re-programmed to your custom board using the J-Link tool and SPI programming process
    • When you try to build a fresh example (at_commands) from our SDK, save it as an image, then program it to your board with the same process, you are unable to confirm that the process is working because you can't observe the normal terminal output after releasing the device from reset
    • You have not been able to successfully program our device on a LaunchPad using the J-Link and SPI programming method

    Is this all correct?

    I see at one point you shared the two images being used to test programming your board with Ryan. I'll check with him if he can share those with me for me to review again and see if there is any obvious difference between them.

    I see you were discussing UART configurations in the application itself with Ryan too. Was that related to understanding the UART programming process or to make sure the UART output (for the application terminal) used by the example application for the LaunchPad matched the UART output pins on your board?

    For UART programming, that is handled by our internal ROM bootloader and no configuration of the application you are building is needed to set it up. You can reference our CC3235MODx Production Line Guide section 4 for details.

    I do think it's a good idea to check that the pins used by the LaunchPad for the UART terminal output (also Pin 46/47 at run-time) match those used on your board for the serial terminal. This can be changed in the application since we have a couple different pins that can be muxed to the UART function and a couple different UART peripheral instances that could be tied to the Display or UART_Print() module.

    Best Regards,

    Ben M

  • Hello Wayne,

    Could you please try the attached binaries?  These should work on both your launchpad board and your custom board.

    For the launchpad, you can use uniflash [CC3235SF(BOOTLOADER)] to program the .sli file.  This will be done over UART to the CC3235SF and the reset logic will be handled automatically.  You should ensure you have SOP0=0, SOP1=1, SOP2=0 (defaults).  You will need to specify the COM port, which will be the USER UART.  This process will take about 45 seconds.

    For your embedded board, you can use your segger programmer to program the .hex file directly into the Serial FLASH using SPI.  The module should be powered, but held in reset while programming the .hex file.  Please also ensure that the flash is first erased before programming the .hex file and I would recommend doing a read-back verify to ensure successful programming.  The first boot after programming, you should use SOP0=0, SOP1=0 and SOP2=0 and then release reset.  The file system will then be created (and encrypted) and you should expect to wait about 45 seconds for the first characters on the UART output (module pin 46 [device pin 55]).  

             ==============================================
                AT Commands Example Ver: 1.1.2
             ==============================================
    
             CHIP: 0x31100019
             MAC:  3.7.0.1
             PHY:  3.1.0.26
             NWP:  4.13.0.2
             ROM:  8738
             HOST: 3.0.1.71
             MAC address: 90:e2:02:28:a6:8d
    
             ==============================================
    
    
    +eventnetapp:ipv4_acquired,10.123.45.1,10.123.45.1,0.0.0.0
    Enter AT Command:
    

    at_commands_CC3235SF_LAUNCHXL_tirtos_ccs-customMODboard-production.7z

    Hope that helps,

    ~roger

  • Sorry for the delay...  I programmed the chip on our custom board with the hex file you supplied, but it results in the same behaviors, no header message was output.  As a reminder, our old production process has a valid load module that does work.  This suggests that something in the development tools process is not working right.

    I a verify of the chip and that indicates that the module loaded matched what is on-chip.  But when I try a read-back, it appears that the memory is different.  Is this due to the unpacking process?

    Read-back screen shot:

  • Just figured out how to capture the entire read-back image as a Intel .hex file and a dump file (with ASCII translation).  Let me know if I should message these directly to you. 

  • Hi Wayne,

    Yes, the difference you are seeing should be due to the unpacking process where the device takes the image and extracts it into the actual file system with encryption.

    It would be interesting to look at the dump file, so you can go ahead and directly message me.

    It really looks like the programming process is good as you have mentioned. The image generation from the tools should be okay too since it hasn't changed.

    I'm wondering if we should try with a simpler example code to make sure there isn't a difference in the pin-muxing causing us to get hung up. Any chance you have the CC3235 tied to an LED on your board and we could try a simple application that just sets an I/O to output and toggles it periodically?

    Best,

    Ben M

  • Hi Wayne,

    One more quick question -> Could you share the schematic for your board with me via direct message?

    That would make it quicker to double check that all is good with the pin muxing or for us to provide other suggestions on what we could test.

    Thanks!

    Ben M