CC3235MODASF: GPIO pull up configured but not working

Hi,

see here https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1069727/cc3235modasf-gpio-pull-up-don-t-seem-to-work

Apparently, the strength of the internal pull up is not high enough so it was suggested to use an external resistor.

Shlomi

Hi Shlomi, thanks for the response (especially on a Sunday!),

I'd seen that post, but I'm afraid that doesn't really answer the question.  The hardware guide says the pull-up current is typically 10uA.  That plenty to pull a 10 Megohm 'scope probe high, and I've seen these pull ups work on the CC3235MODASF on other projects (one on which we've made over 500 units now), so I'm pretty certain my issue (if not that of the OP of the other post) is that something's gone wrong in the SDK - apart from anything I'm now using Code Composer 12.5 (rather than 10.0), and sdk_7_10_00_13 rather than  sdk 4_20_00_07.  I'm also using Uniflash 8.4 rather than 6.2 (but I doubt that could make this change).

Certainly sysconfig seems really significantly difference between those two environments.

(I should add that I would *expect* a finger dabbed on a weakly pulled-up input to trigger it as a result of body capacitance to nearby 50 or 60Hz power wiring.  10uA at 3.3V is an equivalent resistance of 330k, so a 10M probe is going to barely tickle it - Are you familiar with Ohm's Law?  I realise if your life has been purely software you may not be).

Hi Chris, thanks for the info. Sunday is a working day here (weekend is shifted by 1 day :)).

Are you saying that it used to work for you on the same hardware but older SDK or also different hardware?

In order to eliminate this being my hardware, I took an old board running the old firmware (which uses the old SDK), and measured the pullup voltage and current.  As expected, the voltage across the setup switch when open was exactly the power supply voltage (in this case 3.2V from a new CR2 battery).  I used an old-school moving coil meter to measure the current the pullup could provide - that came in at 8uA, which is close enough to the datasheet figure (10uA).

When I update the board with my new project, there is zero voltage measured across the switch (and zero current).

So something about my new project (or the use of the newer SDK) is breaking the pullup.  Would it be helpful if I were to upload the two project files?

With thanks in advance,   Chris

And finally, I pushed the old project to the new board, and the pullup worked as expected, again indicating that there is something wrong with the way my new project is driving the GPIO setup.

I have spent much of the day trying to triangulate this problem.  To do this, I've back-migrated my source files from the CCS12.5 environment to the CCS10.0 environment.  I find that if I build with CCS10, the pullups work fine on both new and old hardware.  But if I build with CCS12.5, they don't.

It does not make any difference which version of the Service Pack I use, or which version of Uniflash I use

Unfortunately my app uses the more recent version of UART2 in CCS12.5, so it won't actually run properly when complied uncer CCS10.0, but does enough to allow me to confirm that pullups are active on both GPIO22 (my setup pin), and on GPIO6 (which I'm using as a test input) when complied with 10.0

I have attempted to get the syscfg stuff as close as I can, given the differences, and I've attached zips of the one which works under 10.0, and the pair (commmon and image) for 12.5, in case you're able to review what I might have done wrong.

syscfg_125.zipsyscfg_10.0.zip

Hi,

It cannot be related to the servicepack or Uniflash.

Syscfg is probably the blame.

Let me ask internally who is the expert on syscfg to assist here.

Regards,

Shlomi

Look forward to hearing back. 

One additional piece of information: when comparing the projects I noticed the 'working' project had the initial stack space set to 2048, whereas the non-working was set to 1024 - changing this made no difference.

Appreciate your continued help.

sure, I should be in the office tomorrow and will try to see if I can test myself.

Hi,

I can share that it is reproducible on my side with the new CCS/syscfg.

I will download an older version and retry just to make sure.

If this is a syscfg issue, I need to see who can assist and redirect.

Regards,

Shlomi

Good to know it is reproducible.  Please let me know if you need any more of the project elements to allow deeper diagnosis.

I tried CCS10+syscfg1.8 and it works.

CCS11+syscfg1.12 no longer works.

Let me look internally who is the right expert to assist.

Shlomi

OK - sounds like a clear bug, then - or the newer sysconfig requires the user to 'do something new' which neither you nor I know about. 

Just for reference, I'm trying to use CCS 12.5, which uses syscfg 1.18.

clear, thanks for confirming.

After spending some time digging around in the various bits of generated code, looking at the source for the libraries, and , I discovered that pin.c contains the code to set up the pads (which - being naive - I'd not realised that 'pads' are different from 'GPIOs' - but now I know).  It took me a while to understand that the pin numbers in the sofware are those on the IC inside the module - not the pin numbers on the module (obvious once you know...) - I gleaned that by  examining chapter 16.8.1 of SWU543A

Having navigated those mazes, I have found that by adding the following code to my main thread I can make the pullups turn on:

The call to PinConfigSet() does what I need to do.

The commented out call to GPIO_setConfig() - which I'd have expected to do what's necessary - does not.

So for the time being I have a workaround which I can use to keep my project rolling whilst using the newer toolset.

I still feel this should not be necessary, and look forward to a 'proper' answer from TI.  Do please continue to try and find one, if not for me, for those other poor souls out there...

Thanks for the update, still trying to understand who covers this code.

Shlomi

Apologies for delay in responding, and thank you for this information, I have now created a new thread in 'Tools'.

I've discovered another anomaly - GPIO9 does not work as an output when configured for that purpose.

I think I may be close to understanding what's going wrong - see

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1343815/launchcc3235mod-sysconfig-not-setting-up-gpio-pull-ups-correctly

It looks as if Sysconfig doesn't always work correctly when GPIOs are deleted.

Thanks for the info Chris.

Let's see what the tools team responds with.

Regards,

Shlomi

Chris and Shlomi,

I downloaded the zip files above (syscfg_10.0.zip and syscfg_125.zip) and noticed that common.syscfg is different between them (as expected, since the 10.0 version is an attempt to back port some of the changes), and also that the SDK used is different between them.  In order to determine if this issue is due to a change in SysConfig, or a change in the SDK, I ran the following on the command line:

c:\ti\sysconfig_1.8.0\sysconfig_cli.bat --product c:\ti\simplelink_cc32xx_sdk_4_20_00_07\.metadata\product.json --output c:\temp\1.8\ "C:\temp\syscfg_10.0\common.syscfg"

c:\ti\sysconfig_1.12.0\sysconfig_cli.bat --product c:\ti\simplelink_cc32xx_sdk_4_20_00_07\.metadata\product.json --output c:\temp\1.12\ "C:\temp\syscfg_10.0\common.syscfg"

c:\ti\sysconfig_1.8.0\sysconfig_cli.bat --product c:\ti\simplelink_cc32xx_sdk_7_10_00_13\.metadata\product.json --output c:\temp\1.8_newSDK\ "C:\temp\syscfg_10.0\common.syscfg"

c:\ti\sysconfig_1.12.0\sysconfig_cli.bat --product c:\ti\simplelink_cc32xx_sdk_7_10_00_13\.metadata\product.json --output c:\temp\1.12_newSDK\ "C:\temp\syscfg_10.0\common.syscfg"

The 3rd command failed, as the newer SDK uses features that are not available in the older version of SysConfig.  This is also why I didn't try comparing the newer script with different versions of the SDK/SysConfig - it has changes that aren't compatible with the older SDK.

Otherwise, what I observed is that the output in the first two folders (older SDK, different versions of SysConfig) are identical.  The output in the last folder is quite different from the first two, as the SDK appears to be generating fairly different structures for GPIO now.  As a result, this looks like a change in the SDK is causing this difference and not a change in SysConfig.

Please let me know if I'm missing something with this setup.  Otherwise, Shlomi, can you please forward this issue onto someone on the SDK team?

Darian

Thanks Darian,

As I stated, it looks to me like something in the TI drivers layer in the SDK. Do you know which group handles the CC32xx base SDK (not specifically the Wi-Fi which is us)?

Regards,

Shlomi

Hi Darian,

Thanks for carrying out the tests you've described - my out-take from that is 'don't try and migrate SysConfigs - start from scratch every time, which is effectively what I ended up doing.

Just to be clear, there are two distinct issues here:

1) Lack of pull-up when using 'all new' CCS, SDK and newly-built SysConfig:  I've got round this - for now - by adding code specifically to enable the pull-ups.  I believe Shlomi has clearly isolated the fact that a mask is not being correctly set

2) Failure to set a GPIO to output if you 'irritate' the SysConfig by switching a UART from 'Transmit and Receive' to 'Transmit only', which of course releases a GPIO, and that seems to throw out the config of otherwise working GPIOs, even if they are not related to the UART.

I much appreciate your efforts to get to the bottom of these issues.