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.