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.

CC3235MODAS: About the need for external Flash

Part Number: CC3235MODAS
Other Parts Discussed in Thread: UNIFLASH, CC3235MODS, LAUNCHXL-CC3235S, SYSCONFIG, CC3235S, SYSBIOS

Hi
We are currently debugging a product using CC3235MODAS.
We wrote the CC3235MODAS program from CCR and it finished normally, but it doesn't seem to be running.
As a confirmation of operation, we toggle GPIO every time we go through the main() loop, but there is no response.
As I posted last time, we can't even debug via JTAG because we can't set the TCK pin correctly, so we have no idea what's going on.
(Article: CC3235MODAS: JTAG_TCK cannnot set the module pin21)

So I have a question,
1. Is it correct to recognize that if there is no external Flash with the CC3235MODAS configuration, writing the program in CCR will be written to the built-in ROM?
2. Does CC3235MODAS absolutely require an external Flash?

  • Sorry!

    CCR→CCS(Code Composer Studio)

  • Hi,

    CC3235MOD have inside 4MB SPI flash (called sFlash). From this reason you don't need to connect another SPI flash chip to your module. This sFlash chip is used as non-volatile storage (firmware image, service pack, web files, user files, etc.).

    CC3235MODS have 256kB RAM which is used for a code execution and your variables (stack, heap, buffers, etc.). When is code debugged from CCS, code is loaded via JTAG into RAM. But for this purpose you need to have device programmed at development via UART (using software Uniflash of CCS ImageCreator). Details how to switch into development mode you find here or here.

    But I think at first step your should ask TI for review of your hardware here.

    Jan

  • Hi, Jan

    Thank you for your advice.

    The reviews you have advised are in our consideration. By the way, as a supplementary explanation, we have connected an evaluation boards(LaunchXL-CC3235S and LauchCC3235SF) instead of CC3235MODAS of our hardware prior to product using CC3235MODAS, and we have confirmed that the expected operation is possible.
    However, we couldn't confirm that the code is running in the original CC3235MODAS configuration, so that's why we asked about these differences, whether with or without of External-Flash is related to the expected behavior.

    From the advice, we understand that sFlash can also be UniFlash and BOOT is possible.
    We suspect that there is something wrong with the configuration on the CCS rather than the hardware connectivity issue (especially the configuration related to the sFlash only configuration on the CCS). Because it works well with the Evalation boards.

    We tried both Develop / Production in Development mode in CCS, but as a result, we still couldn't confirm that the code was running.

    Best regards.

    Thank you.

  • Hi,

    From information above I am not sure what you exactly tried to do.

    At first step please try to connect your board via Uniflash software (using UART connection - RX, TX, RST, GND). How to connect module via LaunchPad you find here at chapter 4.4. Make sure that you use proper SOP mode. After successful connection please provide screenshot of Uniflash status window.

    What is your current SOP mode?

    Jan

  • Hi, Jan

    Thank you for your reply.
    Here is a screenshot about Uniflash as blow, and SOP mode is SOP[2..0]=[010](UARTLOAD_FUNCTIONAL_4WJ).

    Best regards.

    thank you.

  • Hi,

    No. Please follow procedure how to use Uniflash according link which I provided you at previous answer.

    btw ... when is SOP mode 0-1-0 be aware that you need pull-up at UART RX line when RX line is not connected.

    Jan

  • Hi, 

    Thank you for your advice.
    So, I am not sure if it is the status window, but i try to post as  below.

    And then, about the circuit. We have made some changes to our latest configuration.
    1. The RX line of the UART for writing sFlash in now, has a pull-up resistor.
    This is because we made it to write Firmware via Launch-PAD.
    2. JTAG pull-up resistors has been changed to WiFi power (P3R3V_WiFi)
    3. The nRESET line has been changed to wired logic via a diode so that it can also be reset from the microcontroller (MCU_WIFI_RST) or Launch-PAD (DBG_WIFI_RST).

    Best Regards.

    Thank you.

  • Hi,

    According screenshot above your device is at development mode. At this mode you should be able debug via JTAG from CCS. If you are not able debug at this mode, it is likely a hardware issue and please ask for review of your design. You can also see this design checklist by yourself. For example you shouldn't have 4k7 at JTAG lines.

    When your device have SOP mode 0-1-0 and you have 10k at GPIO2 (and not holder by other circuits at low), there should not be any reason that your code is not executed after flashing into sFlash (by the Uniflash or CCS Image Creator).

    Jan

  • Hi,

    Thank you for your advice.

    We are unable to debug via JTAG for CC3235MODAS due to the problem that the TCK pin cannot be set to pin # 21 in sysconfig.
    relatee article:
    https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1092766/cc3235modas-jtag_tck-cannnot-set-the-module-pin21/4049553#4049553

    We are waiting for a patch. So I'd like to ask, is it possible to debug via JTAG if the device is temporarily set to CC3235S and all pin settings are set to CC3235S instead of CC3235MODAS?

    Best Regards.

    Thank you.

    p.s. We have already offered a hardware review..

  • Hi,

    I don't think there is any relation between your debug issue SynConfig issue. Because JTAG connection is opened before pinmux code related to SysConfig is executed. I think your issue is related related to your JTAG connection which is not done according recommendation of manufacturer.

    Yes, you can select CC3235S at settings for your CC3235MOD. Because inside module is CC3235S QFN chip. How pins of module are mapped at internal QFN you find at datasheet for module. Be aware that pins of module are not mapped to exact same pins of internal QFN.

    Jan

  • Hi,

    Thank you for your advice.

    We tried debugging via JTAG with the CC3235S QFN pin settings.
    As a result, an error has occurred and debugging via JTAG has not been reached.
    The errors are Error-242 and Error-1170, and we see Error-1170 every time.

    As advised in the past, we also removed the JTAG 4.7k pullup, but the error still occurs.

    How can we resolve this error?

    P.S.
    We checked the Hardware Design Checklist. The following 4 points are still not match the recommended conditions.
    However, we don't think it will be affected by debugging via JTAG, are they correct?
    - No 100k resistor on TX line.
    - No 2.7k or stronger pull-up or pull-down on open GPIO pins (we think "Glitch on GPIO" may occur).
    - GPIO05 and GPIO07 are not used as external test points.(=open) 
    - RF ABG pin (# 31 @ CC3235MODAS) is open (because we only intend to use the printed antenna included in the MOD).

    Best Regards.

    Thank you.

  • Hi,

    Just to be sure, do you have connected XDS110 to correct pins of module 21 - JTAG_TCK, 22 - JTAG_TMS, 18 - JTAG_TDO, 12 - JTAG_TDI, GND. Right? Maybe you can try to use debug via two wire SWD (change target configuration at CCS, change SOP mode, restart module).

    Error codes above not move us forward. It signalises hardware connection issue with debug probe. For example error code -1170 is commonly shown when you try to communicate with device which is not development mode. But this is not your case because we this checked via Uniflash already.

    Your connection issues are likely due to hardware issue or manufacturing issue (wrong solder joints under module). Please wait for hardware review from TI side.

    Yes, I agree that changes described above not seems to me important as well.

    Jan

  • Hi,

    Thank you for your advice.

    So, I'm sorry to hear the entry-level.
    We have tried FUNCTIONAL_2WJ (SOP [2..0] = 001) mode, but immediately after pressing the debug button on CCS we got the following error:

    We also checked the JTAG wiring and confirmed that the connection was correct.

    What should the correct procedure, if we debug with FUNCTIONAL_2WJ?
    1. Write a F/W with UARTLOAD_FUNCTIONAL_4WJ, and switch SOP to FUNCTIONAL_2WJ between writing.
    (Expected to be reset and switch SOP mode after writing a F/W)
    2. There is a setting in CCS that allows JTAG debugging directly without building and write a F/W.

    Best Regards.

    Thank you.

  • Hi,

    For debugging via SWD you need to:

    1. switch device into development mode by Uniflash (you have done this already, but you can check this again)
    2. connect debug probe via TDI, TDO and GND
    3. set SOP mode 0-0-1 (2-1-0) for Fn2WJ mode and after that restart device to apply SOP mode
    4. set target configuration at CCS to CC3235S_SWD
    5. start debug session

    Technically it is possible connect debug session to already running code, but this not change anything because your debug connection is not working.

    Jan

  • Hi,

    We tried to build another debugging environment to see the JTAG Issue, but it took few days to build.
    By the way, we tried following your advice and we got the following error:

    Error connecting to the target:
    (Error -615 @ 0x0)
    The target failed to see a correctly formatted SWD header. The target failed to see a correctly formatted SWD header.
    connection to the target may be unreliable. Try lowering the
    TCLK setting before trying again.
    (Emulation package 9.4.0.00129)

    What should we do?

    For reference, the version of the development environment being debugged are as follows.
    CodeComposerStudio Version: 10.4.0.00006 + SimpleLink CC32xx SDK 5.20.00.06

    In addition, Image Mode is set to Development.


    The device also selects CC3235S_SWD.


    Then, after confirming the completion of Flash writing from CCS, debugging is started after that.

    Best Regards.

    Thank you.

  • Hi,

    Did you asked TI for review of your hardware? Do you have response?

    Error code -615 at SWD does not move us forward. Because this is general communication error at SWD mode. For example it is shown when you disconnects TMS and TCK jumpers at LaunchPad.

    Jan

  • Hi,

    Thank you for your advice.
    So, the review, I submitted on last week(Apr-19), and have no respond yet.

    Best Regards.

    Thank you. 

  • Hi,

    Following your advice we checked the connections (TCK, TMS) and they were fine.
    The waveforms of TCK and TMS are as follows. (CH1 = TMS, CH2 = TCK)


    The waveforms are observed on our board.
    In our debugging environment, we use LAUNCH-XLCC3235S as an emulator (Debug probe) and connect it to our board (via jumper wire and FPC).


    The total wiring length is about 20 cm (8 in).
    However, the result was (Error -615 @ 0x0) as before.
    Is there anything we have to do?

  • Hi,

    As to be honest, I don't have much confidence to your JTAG connection (jumper wires -> PCB -> ribbon cable). But I will believe that TCK and TMS connection are correct.

    How is done your GND connection? It is done via small wire connected to hook at Launchpad under your cardboard?

    Maybe you should check whether your SOP mode is properly selected.

    If you have access to X-ray machine or BGA inspection cam, maybe you should check solder joints under module.

    I think TI should respond you at three business days after your design review submit. If this take a longer time, you can open new thread at e2e forum (with reference to this one) just for "ping" of TI engineers.

    Jan

  •  Hi,

    Thank you for your advice.

    About the GND, they are contacted through the copper foil tape on the back side of the cardboard, with some tin-coated-wires.
    (The EvaluationBoard is from the GND TP2 terminal, the intermediate board is from a GND pin, and our original board is from the GND plane.)

    And I took a look at the solder joint with an X-ray inspection device, then I could see some voids under the solder pad, however it's enough to connect,  I think.

    Best Regards.

    Thank you.

  • Hi,

    From my point of view solder joints looks OK, but I am not expert at this filed. I think next step is design review from TI side, because I ran out of ideas.

    Jan

  • Hi Jasse,

    Thank you very much for your advice. And it took a long time to reply because of our long vacation. sorry.

    By the way,  We tried various checks with reference to the page you taught us, but we have not solved it.
    The error is either Error -242 or Error -1170. (almost -1170)
    As we check, we did some modifications.
     1. We removed the pull-up resistor left on the TDO line.
     2. The length of the FFC connected to the original board has been shortened (10cm-> 5cm).
     3. The pull-down resistance of SOP0 and the pull-up resistance of SOP1 are set to 68k (the resistance value on hand that is closest to the recommended 69.8k). (SOP[2..0]=[010])
     4. Added one GND line from the FFC intermediate board.

    Also, we checked the JTAG signal on LAUNCH-PAD (LAUNCH XL-CC3235S).
    --The signal when the LAUNCH-PAD alone (debugging is available).
    --The signal when the emulator on LAUNCH-PAD, connected to the original board with JTAG (TMS, TCK, TDI, TDO) and RESET(errors are happen).
    We didn't seem to have any difference in the waveform.

    As a supplement, we watch each core by the following operation (Target Configuration --Launch Selected Configuration --Show all cores) and try "Connect Target" to IcePick_C, it is OK, but with CS_DAP,
    We can see the error -242 or -1170.

    What more should we do?

    Best Regards.

    Thank you.

  • Hi Toshio,

    In your response to the hardware review you mentioned UniFlash was working fine. Were you able to flash your program to the CC3235MODAS using UniFlash?

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your reply.

    Yes. We have checked that it works fine with Uniflash.
    However, when we try to work again, it seems that some procedure is required, and if it is not good, an error of -7 will occur. (The RX signal remains L for a long time and then becomes time out.)
    Currently, we push "Load Image" botton on Uniflash, and after RX becomes L, then turn on the WiFi power on the original board, it becomes fine.

    Best Regards.

    Thank you.

  • Hi,

    Here is a additional information.

    We have been wondering for a while days, then, after the power is turned on, the TX(WiFi->XDS110) pin of the UART outputs each two Lo pulses with a cycle of about 420ms.
    We are wondering that the WiFi module suspects a periodic reset.
    Where should we check ?
    (assuming the cause is not due to WiFi module power, nRESET)

    (CH1: nRESET, CH2: P3R3V_WIFI, CH3: WIFI_DBG_UART_WRX (MOD: 47pin), CH4: WIFI_DBG_UART_WTX (MOD: 46pin))

    Best Regards.

    Thank you.

  • Hi Toshio,

    I'm not familiar with the -7 error you mentioned you were seeing in UniFlash. Was there a description of the error? When you are able to successfully flash to your CC3235MODAS via UniFlash, does the application run on your board as expected?

    Can you try the following steps? As you start, make sure you have verified proper UART connection (RX, TX, RST, GND) from the launchpad to your custom board and that SOP pins are [010].

    When you are using UniFlash, make sure you are using the Image Creator tool within UniFlash. Do not use the Auto-Detect feature, instead ensure CC31XX/CC32XX or even LAUNCHXL-CC3235S is selected (as shown below) and then click "Start Image Creator". Do not select CC3235(BOOTLOADER).

    Start a new project by clicking "New Project", enter name and description for your project and make sure device type is set to CC3235S and Device Mode is Develop

    To add an MCU image to the project, click Browse and navigate to your application BIN file. If you are developing with CCS, this BIN file will typically be in your CCS workspace in the project's Debug folder.

    You should then be able to ConnectBurn, and Program the image to your device. These steps are outlined in Section 4 through Section 5.5 of this guide: https://www.ti.com/lit/ug/swru469h/swru469h.pdf#page=7&zoom=100,0,102. Similar details are found in this guide Jan linked recently as well: UniFlash ImageCreator Basics (ti.com).

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your advice.

    We have confirmed with your advice that it works fine with Uniflash.

    However, there was one problem. When resetting from LAUNCH XL-CC3235S (TM4C1294NCPDTI3R), the nRESET level on the original board may be about 0.72V, which may deviate from the device requirement (VIL (nRESERT) = 0.6V (typ)) and may not be reset. I found out that there is. We temporarily changed the R17 (10kohm) of LAUNCH XL-CC3235S to 5kohm and it works fine.

    By the way, even if we select our application BIN file when specifying the MCU Img on UniFlash, the file name will be mcuimg.bin.
    Should this be written in Advanced mode?
    Or is it better to leave the file as mcuimg.bin at this stage? (This is because when debugging, CCS will go to write the image to the built-in RAM on CC3235S, that is, it will not depend on the contents of sFlash)

  • Hi Toshio,

    I'm glad to hear that UniFlash is working fine now.

    When flashing through UniFlash and you select the .bin file to program to the device, it will always appear as mcuimg.bin

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your reply.

    I got about UniFlash filename.

    So, from the successful writing with using UniFlash, we can assume that our CC3235S is working properly.
    Considering this, I think that JTAG can also working normally, but unfortunately the following error has not been resolved and debugging via JTAG has not been working.
    (A) Error -1170 @ 0x0 Cannot access the DAP
    (B) Error -242 @ 0x0 A router subpath cannot be accessed
    I referred to the "Debugging JTAG" web page that you taught me, but I didn't find anything suspicious here.
    -From the good operation of UniFlash, I think that the UART connection and SOP setting are correct.
    -The JTAG waveform does not seem to be different from when LAUNCH-PAD is operating alone, so I think there is no problem with JTAG connection.
    Where should we check to make a good JTAG connection? (settings, procedures, etc ..)

    Best Regards.

    Thank you.

  • Hi Toshio,

    Can you try these steps to see if debugging in CCS works?

    1. Import the hello_CC3235S_LAUNCHXL_tirtos_ccs example project into your CCS workspace by clicking Project -> Import CCS Projects and then browsing to the examples/rtos/CC3235S_LAUNCHXL/sysbios/hello/tirtos/ccs folder in the SDK. 

    2. Don't change any of the settings, just build the project.

    3. Verify JTAG connections from the LaunchPad to your board (RST, TMS, TCK, TDO, TDI, GND) and that SOP pins on your board are [010]


    4. Click "Debug" to launch the debugger in CCS. If you see the -1170 error at first, reset the board and launchpad and try again.

    5. Click "Resume" to run and you should see Hello world printed to the console.

    You can also open the CC3235S.ccxml file under the targetConfigs folder in the project and click "Test Connection".

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your advice.

    I tried the sample SDK Project and it works fine!!

    Just a note to confirm.

    Best Regards.

    Thank you.

  • Hi Toshio,

    Glad to hear you are able to debug now.

    You should be able to debug your project as well, as long as you have the default CC3235S.ccxml file and CC3235S as the device and default as the package (not mod) in the board or device settings in sysconfig.

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your reply.

    From these fact,
      1. CC3235S  on our original board is alive.
      2. There is no problem with the connections between LAUNCH-PAD and our original board.
    ... was what we found out.
    Then, it is considered that there is a(some) key(s) that works / does not work in the difference between the sample project and our project.
    What should we check first?
    Examples are my idea...
     1. Difference between nortos and rtos
     2. Differences in settings somewhere (I don't know exactly where)
     3. Difference in configuration

    As a supplement, I tried the following experiments.

    A. CC3235S.ccxml was different between the sample-project and our project.
      So, replece the file.
      Conclusion : "Error -1170" has occured.

     difference example, 1st one is our project, 2nd one is the SampleProject
         Line3:<configuration XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
         Line3:<configuration XML_version="1.2" id="configuration_0">

    B. Import a sample project from "..\nortos\CC3235S_LAUNCHXL\demos\trigger_mode\ccs"
     And then "Build Project" -> "Load SLI Image to Serial Flash" -> "Debug"
      Conclusion : "Error -1170" has occured.
        (screen shot as below)

    Best Regards.

    Thank you.

  • I forgot to say that  ".. \ nortos \ CC3235S_LAUNCHXL \ demos \ trigger_mode \ ccs" is the basis of our project

  • Hi Toshio,

    I don't think the issue is with nortos and rtos. The issue is likely a difference in settings or configuration.

    Sometimes the -1170 error is seen when the device just needs to be reset. Can you try:

    1. Import the trigger_mode_CC3235S_LAUNCHXL_nortos_ccs example project again. Don't change any settings.
    2. Build the project (Right click on the project -> Build Project)
    3. Attempt to debug. (Right click on the project -> Debug As -> Code Composer Debug Session)
      1. If you see the -1170 error the first time you try to debug, reset your CC3235MODAS and try Step 3 again.
      2. If you see the -1170 error again, try resetting the LaunchPad by clicking SW1 - RESET and try Step 3 again.

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your advice.

    We had a progess. (But still tiny..)

    (1) We tried the steps in you advise (Build Project-> [SW1: Reset]-> Debug As-> Code Composer Debug Session in trigger_mode) but all were unsuccessful.
    (2) We tried another sample project (..\ti\simplelink_cc32xx_sdk_5_20_00_06\examples\nortos\CC3235S_LAUNCHXL\drivers\display\ccs).
    This also didn't work for us with the advice given, but with this procedure (Build Project-> Load SLI image to serial flash-> SW1: Reset-> Debug As-> Code Composer Debug Session) Debug mode was successful. Also, Resume (F8) was fine.
    (3) Following (2), in "trigger_mode", we reach the "first step" of debug mode in your procedure (Build Project-> SW1: Reset-> Debug As-> Code Composer Debug Session). But we got an error in Resume (Error-242 or Error-1170).
    (4) Following (3), in "trigger_mode" we have the following steps (Build Project-> Load SLI image to serial flash-> SW1: Reset-> Debug As-> Code Composer Debug Session) We got an error (Error-242 or Error-1170) and couldn't even reach the first step in debug mode.


    Fig 1. Debug at the sample "display" in (2)


    Fig 2. Resume at the sample "display" in (2)


    Fig 3. Debug at the sample "trigger_mode" in (3)


    Fig 4. Resume at the sample "trigger_mode" in (3)

    In addition, the SDK (..\ti\simplelink_cc32xx_sdk_5_20_00_06\examples\nortos\CC3235S_LAUNCHXL\demos) sample was unable to reach debug mode with or without Load SLI.
    As a side note, it was the same as (2)-(4) with "trigger_mode" in the sample stored in "..\ti\simplelink_cc32xx_sdk_5_20_00_06\examples\nortos\CC3235S_LAUNCHXL\drivers" of SDK .
    (However, "watchdog" did not enter debug mode due to an error as in (4))

    From the above results,
    a) The difference between RTOS and NoRTOS does not matter whether debugging is possible or not. (we confirmed what you said)
    b) In NoRTOS the "demos" sample project doesn't all work with our CC3235MODAS in debug mode.
    c) We were able to reach the first step in debug mode with "trigger_mode" only after with Load SLI in the NoRTOS "drivers" sample project.

    In todays progress found, that the key is in the "Load SLI" and "driver" sample projects. But we got nothting found key(s) to go beyond Resume (F8).

    what should we do?....

    Best Regards.

    Thank you.

  • Hi Jesse,

    We have more progress. (Here is a huge step!)

    We found an error at Resume what I told, but use step execution at this time, it is walk fine.
    The error couse of "sl_DeviceEnable()"
    (may be at NwpPowerOn() in cc_pal.c)

    Thank you for your cooporation.

    The only remaining matter for us. Why doesn't it work without Load SLI Image in the "drivers" sample project?

    Best Regards.

    Thank you.

  • Hi Toshio,

    I'm happy to hear you made progress and found the error.

    I'm not exactly sure why debug wouldn't work without Load SLI Image in the "drivers" sample project. Try changing the Build Configuration for the project to "Debug" rather than "MCU+Image". Click the drop down arrow next to "Build" and select "Debug", as shown below. 

    Build the project, then try to debug again. If you see the -1170 error at first, try resetting the device and try to debug again.

    Best regards,

    Jesse

  • Hi Jesse,

    We have tried that change the "Build" is from "MCU + Image" to "Debug".
    It was fine, but it was still assumed that "Load SLI Image" in the "sample project" of the "driver" with our original board.

    With LAUNCH-PAD alone, Debug was OK regardless of the type of sample project, whether or not "Load SLI Image" was executed. We feel that there is some difference between LAUNCH-PAD and our Original board.

    Although our small problem remains, this issue, which couldn't make a JTAG connection to check that the cc3235s didn't work, can now trace the program.

    Please let us know if the difference may be related to external flash. Otherwise we will resolve this article (Because we are redesigning the printed circuit board now).

    Thank you so much for your support.

    Best Regards.

  • Hi Toshio,

    I'm looking into your question about the difference being related to external flash and will provide an update early next week.

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your reply.

    So, here is a additional information.
    In the trigger-mode sample project that can be debugged without problems with LAUNCH-PAD, we talked about the error in RESUME on our original board last time.
    The difference between LAUNCH-PAD and our original board are
    - The power of LAUNCH-PAD is supplied to all devices.
    - The WiFi module power supply of our original board is controlled by the MCU.
    This has a different power ON timing.

    As a test, we tried to operate the MCU power supply and the WiFi module power supply in common on our original board.
    As a result, the problem of error in RESUME has been resolved.

    The MCU controls the power supply of the WiFi module to reduce power consumption (extend battery life during standby).

    So the question, is it forbidden to turn the power of the WiFi module on and off independently? Or is it possible to turn it on / off independently by attach the timing that describe in data sheet (SWRS215D) "8.17.3 Reset Timing"?

    Best Regards.

    Thank you.

  • Hi Toshio,

    1) Can you be more clear on how the CC3235MODAS's power supply is controlled by the R5F571?

    2) And when you say,

    As a test, we tried to operate the MCU power supply and the WiFi module power supply in common on our original board.
    As a result, the problem of error in RESUME has been resolved.

    , are you saying that you are powering both the R5F5571 and CC3235MODAS with P3R3V_MCU?

    • P3R3V_MCU is coming from IC51, MP2155.
      • This Buck-Boost can supply max 1A of current at 3v3.
    • P3R3V_WIFI is coming from IC19, XC6221D331Gr.
      • This LDO can supply max 200mA of current at 3v3.

    See Section 8.4 in the CC3235MODAS datasheet. The peak calibration current when the device is first powered is 450mA when VBAT is 3v3. It is good EE practice to double the LDO output or more depending on what else you need to power on your board, so it is recommended to power the CC3235MODAS with the MP2155 or an LDO that can output a max current of 1A or more.

    BR,

    Seong

  • Hi Seong,

    Thank you for your reply.

    > 1) Can you be more clear on how the CC3235MODAS's power supply is controlled by the R5F571?

    We describe the power sequence below.
     1. The Battery to be plugged.
     2. Only P3R3V_MCU will be Live.
     3. The pin of POWER_SW on MCU(R5F571) is pressed (enable as H).
     4. When press of POWER_SW  continues for 100ms or more, the MCU determines that the power ON condition has met.
     5. The MCU sets MAIN_POW_EN to enable(H), then turns on the  MAIN_POW.
     6. When MAIN_POW becomes live, then P1R1VD_PG becomes H.
     7. P3R5V_MID becomes live, then P3R3V_WIFI becomes live.
     8. The MCU de-assart (H) nRESET in the initial setting followed in process No 5. describe in avobe.

    Now, a timing between P3R3V_WIFI rise to nRESET rise is about 0.9ms.

    >are you saying that you are powering both the R5F5571 and CC3235MODAS with P3R3V_MCU?

    Yes.

    Test wireing as blow.

    Best Regards.

    Thank you.

  • Hi Toshio,

    In addition the suggestions Seong mentioned above, to answer your previous question:

    Please let us know if the difference may be related to external flash.

    The CC3235MOD already has internal SPI flash. You don't need to connect another SPI flash chip to your module.

    Best regards,

    Jesse

  • Hi Jesse,

    Thank you for your reply.

    The question about the External flash was clear!

    Thank you so much.

  • Hi Seong,

    We have a additional question.
    We think that it is possible to rewrite the Flash(sFlash) of CC3235MODAS via the MCU, and the original circuit connects the pins of FLASH_SPI of CC3235MODAS to the MCU. So, can the Flash inside CC3235MODAS be rewritten from the MCU?
    If it can't be rewritten, do we have to keep the FLASH_SPI signals open?

    And the remaining of our question is below.
    --
    So the question, is it forbidden to turn the power of the WiFi module on and off independently? Or is it possible to turn it on / off independently by attach the timing that describe in data sheet (SWRS215D) "8.17.3 Reset Timing"?
    --

    Best Regards.

    Thank you.

  • Hi Toshio,

    We think that it is possible to rewrite the Flash(sFlash) of CC3235MODAS via the MCU, and the original circuit connects the pins of FLASH_SPI of CC3235MODAS to the MCU. So, can the Flash inside CC3235MODAS be rewritten from the MCU?
    If it can't be rewritten, do we have to keep the FLASH_SPI signals open?

    You can try to re-write the serial flash using your MCU, but this is not typically what the FLASH_SPI pins (shown below) are used for.

    These pins are typically used for programming the serial flash in the production line, as shown in this Production Line Guide. See sections 2, 3, and 4.

    If you do try to re-write the serial flash using your MCU, please see section 8.16.5.9 External Flash Interface of the CC3235MODx Datasheet, which states:

    "The CC3235MODx and CC3235MODAx MCU includes the Macronix 32-Mbit serial flash. The serial flash can be programmed directly using the external flash interface (pins 13, 14, 15, and 17). During normal operation, the external flash interface should remain unconnected.

    For timing details, see the MX25R3235F data sheet."

    So the question, is it forbidden to turn the power of the WiFi module on and off independently? Or is it possible to turn it on / off independently by attach the timing that describe in data sheet (SWRS215D) "8.17.3 Reset Timing"?

    It is ok to turn the module on and off independently as long as the power up timing requirements in the datasheet are met and the power supply can provide enough current.

    Best regards,

    Jesse

  • Hi Jesse, Seong, Jan,

    We appreciate for your many many support.
    All of our issues in this article have been cleared.

    The conclusions are as follows.
    1. Is External Flash required for CC3235 MODAS to work? → It can work without External Flash
    2. There are some hardware mistakes caused CC3235MODAS not to work
    A) 100k pull-up is required for UARTLOAD UART lines
    B) Do not add pull-ups to JTAG lines
    C) It is necessary to comply with the data sheet for the timing between WIFI power-on and nRESET.
    D) An unintentional wakeup and boot of the CC3235MODx or CC3235MODAx module can occur with an external device drives a positive voltage to the signal pads before turning on the WIFI power.
    E) The capacity of the WIFI power supply was insufficient (maximum 450mA (@ 3.3V, peak calibration current))

    3. The above issues worked fine with the fix below.
    A) A 100k pull-up was attached to the UART lines of UARTLOAD.
    B) Removed the pull-ups from the JTAG lines
    C) The timing of nRESET was set according to the data sheet.
    D) Connected our WIFI power supply to the power pin of the external side of the buffer on the LAUNCH-PAD
    E) Temporarily, we connected CC3235MODAS to our MCU power supply. (We will change the WIFI power supply to 1A in the next revision)

    Thank you so much.

    Best Regards.