CC3200 Internal Pulls Not Functioning As Expected

Hello Glenn

I am assuming you are checking MOSI signal.

Could you please try checking the signal with a simple multimeter. Point being that the Logic Analyser would have an internal pull and given that the "pull" strength option in the device is weak, it could get over-ridden 

regards

Manav

Hi Manav,

Yes I am checking the MOSI signal. 

I just measured with a multimeter and it registered around 2.6v even though I have set the internal pull down.

Glenn.

Hi Glenn,

I think the driverlib does not offer too much help in your particular case - and you need to just add some extra code line to do what you need, for instance:

HWREG(GPIO_PAD_CONFIG_14) |= 0x910; // enable open drain, weak pull-up and override

See the swru367.pdf, page 496.

And I would add this line after the SPI mode set (master if this your case).

However, such thing may degrade the leading edge rise-time, since a pull up does not have enough current to charge all capacitances on circuit.

Regards,

Petrei

Thanks Petrei,

I am trying to perform a pull down on the MOSI pin. I tried the following code without any success.

HWREG(0x4402E0E0) |= 0xA77;

The issue may be due to my inexperience with working directly with the registers. Is the 0x910 you provided above correct, or just an example? As I could not calculate this result for the example you provided.

Also, I am wanting to work on the MOSI and not the Clock, so this is pin 7 - GPIO_PAD_CONFIG_16  0x4402E0E0

This is what I have done to calculate the 0xA77

[3:0] CONFMODE = 7 (Dig Pin Mux Config Mode Value)

[4] Enable Open Drain = 16

[7:5] DRIVESTRENGTH = 6mA = 011 = 96

[9] Enable Internal Weak Pull Down = 512

[11] Enable Over-riding = 2048

7 + 16 + 96 + 512 + 2048 = 2679 = 0xA77

Any suggestions?

Glenn.

Hi Glenn,

I have taken the first pin in your code snippet - of coarse you can do the same on MOSI. 

My thinking was: bit11-override, bit8-pullup, bit4-open drain, so 0x910. Maybe 0xD10. I did not mixed with previous settings - try first with standard settings, usually the pin has bigger capability than declared x mA (not tested on CC, but on Tiva).

But I wonder why you set open drain and pull-down on SPI Tx pin - this should have current capability on both directions (source and sink) - depends also on your peripheral - but up to now I did not know any peripheral to need open drain on Tx (except I2C, which is another type). 

Did you set up a breakpoint after that instruction and checked the content of the register? If changed as you wish or unchanged?

Petrei

Hi Petrei,

Thanks for the additional information, good to know the general idea on how to calculate this was correct. I have tried experimenting with a number of settings, but still haven't got it to work as expected. The setting of open drain on MOSI was a mistake.

The register is changed, and I am also getting different behaviour with the MOSI line (no data being sent for example), so it looks like something is happening. I just need to find the right combination of settings.

For now I am using a trusty external pull down resistor to get the results I need.

I am creating a Manchester encoded signal by using an XOR (74HC86) on the SPI Clock and MOSI. To get the right combination (polarity, phase, timing, pull downs etc) is quite fiddly, I had this working on the Tiva C, but now trying to get it working on the CC3200. 

I wonder why the PinConfigSet(PIN_07, PIN_STRENGTH_4MA, PIN_TYPE_STD_PD) is not working? This would make things so much easier!

Glenn.

Hi Glenn,

Some observations:

a) about PinConfigSet() - depends on the order/place where it is written/executed. As a general (Tiva) rule, the last one overrides the previous.

b) about the phase/polarity: since you had a Tiva example working, take into account the modes now are somewhat changed - in Tiva, Mode 1 was declared as "0x2", while now at CC, it is really "0x1".

Petrei

Hi Glenn et all,

> HWREG(0x4402E0E0) |= 0xA77;

pay attention that you "or" the value to the register. It could be that some bits are already set and you just add the bits, not removing the zeroes, perhaps to an unwanted resulting value. Perhaps read the register afterwards to print and check.

Or do something like this (when lowest 3 bits shall be changed):

HWREG(...) &= ~0x07;

HWREG(...) |= 0x02;

In general also check, sometimes some register can be set only, so "oring"/"anding" leads to unwanted results. Sometimes

HWREG(...) = 0x02;

is perhaps better, if no other pins/functions are changed in same register.

About MOSI and open drain: I can think of a case (not CC3200 related at all), where uC is 3.3V, but SPI peripheral is 5V and needs the high level (e.g. on MOSI, SCLK, CS). With an external pull-up to 5V you can pull the voltage higher than 3.3V. But this needs of course 5V tolerant pins.

Best regards,

Martin

Hi Petrei and Martin,

I was just looking into this again and have noticed that  swru367.pdf (Technical Reference Manual), no longer has page 496. It look like the document has been updated, and there is no details on setting the registers for the internal pulls. It does still mention these are available, but does not list the details.

Feel free to check that I am not making a mistake - CC3200 SimpleLink Wi-Fi Wireless MCU Technical Reference Manual (Rev. A)

Glenn.

Hi Glenn,

We updated the TRM, to clarify a few items on the watchdog timer chapter (10).

The pin muxing table was omitted from this release. There was no changes to table. We will post a new version of the document, with chapter 16 reintegrated by the end of the day.

Hi Glenn,

I used the API "PinConfigSet" to enable internal pull, The API works as expected. Please find below further details regarding the test. Please see if this helps if not we can discuss this further.

#1. PinConfigSet API usage :

You have used the API correctly. Even I took the spi_demo code and enabled pull up on "PIN_05 for SPI0 GSPI_CLK" and PIN_07 for SPI0 GSPI_MOSI. Please find below the exact lines of code

PinConfigSet(PIN_05, PIN_STRENGTH_4MA, PIN_TYPE_STD_PU);

PinConfigSet(PIN_07, PIN_STRENGTH_4MA, PIN_TYPE_STD_PU);

#2 Measurement of the Voltage for internally pulled up pins:  

Please note that internal pulls are weak. So any equipment that we use for the measurement should not override the internal pull effect. I made measurements using "Agilent Oscilloscope" and also "Multimeter". I have pasted below pictures of the setup wherein i used Multimeter. You mentioned you used logic analyzer, LA can have its own load effect thereby giving false measurement. Please consider using Multimeter for the measurement.

Measurement of Pin_5 voltage:

Measurement of Pin_7 voltage:

Thanks and Regards,

Siddaram

Hi Siddaram,

Thanks for looking into this. I am actually trying to get the internal pull down functioning and not the internal pull up. By default SPI (CLK and MOSI) is high, so your test is just confirming this.

Can you test the pull down, here is the code:-

PinConfigSet(PIN_07, PIN_STRENGTH_4MA, PIN_TYPE_STD_PD)

And yes, I have used a multimeter directly connected to the pins, same result as the logic analyzer.

Glenn.

Hi Glenn,

On my setup by default SPI CLK and MOSI pins are low and that's why i tried to pull it up and it works. Can you confirm if your test setup is also the same as what i have  described below

1. Nothing is connected on the pins PIN_05 and PIN_07

2. Run the spi demo code and measure the voltage at PIN_05 and PIN_07. The measured voltage is ~0 V

3. Add the two lines of code to internally pull up PIN_05 and PIN_07

4. Run the spi demo code and measure the voltage at PIN_05 and PIN_07. The measured voltage is ~3.26 V

I am not able to understand why by default PIN_05 and PIN_07 are pulled high in your setup. Please help me understand your setup a little bit and also clarify if any changes are done to the launchpad you have.

Thanks and Regards,

Siddaram

Hi Siddaram,

I have run the spi_demo example and these are the results I get, and it makes no difference if I add the pull up code or not.

MOSI - Goes high after it has sent the first packet.

CLK - Remains low. But this depends on Polarity/Phase. In my setup it is high.

I am making the following changes in the pinmux.c file in the spi_demo example

    //
    // Configure PIN_07 for SPI0 GSPI_MOSI
    //
    MAP_PinTypeSPI(PIN_07, PIN_MODE_7);
    PinConfigSet(PIN_07, PIN_STRENGTH_6MA, PIN_TYPE_STD_PU);

I have 2 launchpads and both display the same behavior, they have not been modified in any way.

Would you be able to test the pull down in your setup? As this is what I am trying to do.

Glenn.

Hi Glenn,

Based on your test scenario description I understand that the internal pulls are being used after the SPI module has taken control of the pins.  Once the HW module(SPI) has taken control of the pins the weak internal pulls are ineffective. So internal pull down that you are trying to do after SPI module is initialized will not work.

The internal pulls are helpful in scenarios where there is a need to keep the pins in a known state till the actual HW module takes control of the pins.

Please see if this helps, If not we can discuss this further.

Thanks and Regards,

Siddaram

Hi Siddaram,

Thanks for the confirmation. Looks like external pulls are required for the CC3200.

Is this information documented anywhere, as I could not find anything, or have you come to this conclusion through testing?

Just a few points for others:-

This was not the case with the Tiva C (TM4C123G), as its internal pulls where strong enough to hold the MOSI line down.

I have looked into the CC3200 TRM (Technical Reference Manual) and cannot see any registers that can be set to ensure the MOSI line is low when it is Idle (after the first word is sent). However the TRM does not make it clear that MOSI is high when idle.

Glenn.

Siddaram,

Thank you for the time and effort testing this. With your assistance I have now worked out what the issues were and am able to reproduce the same results as you have described above.

First issue was related to where I configured the pull down in my project, which is a TI-RTOS project, this has now been resolved.

The second issue occurred when testing with the spi_demo example. I had rigged up my wires using a breadboard, I then also connected the LA at the same time as I tested directly with the multimeter. This must have created an issue from the internal pulls of the LA. Once I removed the LA jumper cable from the breadboard and tested with the multimeter it displayed the correct 0 volts.

None of this happened when using the Tiva C LaunchPad or a custom prototype, so I'm assuming the pulls in the CC3200 are a lot weaker.

Thanks again for your effort.

Glenn.

Glenn,

I am glad i could be of help, Many thanks to you as well.

Regards,

Siddaram