GPIO1 setup through enable and reset

Hi,

GPIO1 also needs module enable and module reset.

Please refer the starterware example  "examples\beaglebone\gpio\gpioLEDBlink.c", which uses the GPIO1. This will demonstrates the configuration of GPIO1.

Regards,

M.Jyothi Kiran

Hi Jyothi,

Thanks for answering my questions.

I built that example, freshly, from pure Starterware code, but I still get a hang on 

while(!(HWREG(baseAdd + GPIO_SYSSTATUS) & GPIO_SYSSTATUS_RESETDONE));

in the reset function. Could there be a hardware problem on my new board? What kind of hardware problem could cause this?

I also tried GPIOs 2 and 3 in simple test programs, and they hang in the reset
while() also, auguring it not being a hardware problem. To change to GPIOs 2,
then 3, I just changed the appropriate 1s to 2s in my test program, and then to
3s, also using the correct GPIO registers base addresses.

Hi,

The clock configuration of GPIO requires enabling of two clocks: 1) Functional Clock 2)Optional Clock.  For module reset to happen correctly, it is needed to enable both the above clocks. If we enable only functional clock(not enbaling optional clock), then the reset will not happen and code will hang in the while loop.

Please check whether you have enabled Optional clock also along with functional clock.

Regards,

M.Jyothi Kiran.

Hi Jyothi,

As I said, I built the Starterware example  "examples\beaglebone\gpio\gpioLEDBlink.c", but it still hangs on
GPIOModuleReset(). So it doesn't actually have all the needed code? Why not? Where can I find the code to do the missing setup? Like this "Optional Clock" setup? Can I just be provided with the full, correct code?

First you tell me that "examples\beaglebone\gpio\gpioLEDBlink.c" demonstrates the GPIO1 configuration, then when I build it and it hangs, you tell me it might be missing something. This is ridiculous. This is a never-ending run-around.

I shouldn't have to tell you this, but please read the above message history and try to understand the problem. Provide me with the requested code. If you mention code that is needed, then PROVIDE it.

Hi 335Nov,

         The GPIO reset can hang in the place you mentioned only if the clocks are not provided properly (functional and optional clock). I believe the functional clock is setup properly (as you are able to write to GPIO1 registers).

         Now lets look at GPIO_1_GDBCLK (debounce clock) - This clock comes from per PLL (M2 o/p). So i suspect your per pll is not configured properly. StarterWare beaglebone code might work properly as you might be running the gel file supplied in StarterWare package (under tools folder).The gpio ccs project is configured to use this gel file.

         Are you running any gel file (or board init code) for your custom board, before loading the GPIO1 application ?

        You need to ensure the PER PLL is configured properly.

regards

baskaran

I am not running any board init code through the debugger. I am building a
bootloader, which has to be stand-alone. I am working from the EVM SK
bootloader, and my board is based on the EVM SK. It was getting through the
reset, but then it stopped working, and I don't know what broke it.
See my bl_platform.c file, attached. Is there anything wrong with PerPLLInit()?
PERPLL_M2 = 5.

5707.bl_platform.zip

Seems you have reused the PLL configurations from StarterWare bootloader. You can reuse the same values if the Master oscillator is of the same frequency as in EVMSL board (which is 24MHz).

What is the master osc clock frequency in your custom board.

Regards

Baskaran

Also share your GPIO Module clock config, enable and reset code.

Yes, I believe I have reused the PLL code from the StarterWare bootloader.
The master osc clock frequency on my custom board is 720 MHz, and it uses the
same 24 MHz crystal.
Attached is the GPIO code.
Attached: GPIO_and_Hs.zip:

5148.GPIO_and_Hs.zip

This code works in the EVM SK module, and the only other difference is changing the debug driver between my board and the EVM SK, otherwise using the exact same IAR project. I don't believe the problem is hardware, since this is all in the micro itself, and in these areas my custom hardware is the same as the EVM SK, so there must be some little-known setting to put in the code. This issue probably needs to be escalated.

Hi 335Nov,

           At this point i can suspect 2 things,

1. Debug driver - I believe you are using different emulator than xds or j-link (supported in StarterWare). I am not sure if your debugger executes something before the actual code. You need to check the configurations of the debugger. To isolate whether it is debugger issue you can load the image via uart or mmc sd (uart or mmcsd boot modes) and check if it works.
2. HW - why do you think HW will not have any issue. Is there any diagnostic run on the board and that passes ?. have you got any other examples working on your custom board ?

Regards

Baskaran

I am using the "TI XDS 100/220" driver on the EVM SK module and the
"I-jet/JTAGjet" driver when on my custom board. I said, a few replies ago, that
I am not running any board init code through the debugger. I am attaching my
IAR project. I don't think there is anything wrong with the configuration:
please check it and confirm. I can't load code via the UART or the MMCSD because
boot modes aren't designed-in to my new board.
I really don't think the problem is hardware because a lot of things are working
in the micro: I can connect and debug via JTAG, GPIO0 works, and the PLLs all
initialize successfully to access the SDRAM on the board, the same as on the EVM
SK. I have the same micro as the EVM SK, the XAM3359. What hardware problem can
be so selective as to target only GPIO1-3? I would really like to know that.
Please access your resources and find out for me what hardware problem would
affect only GPIO1-3. Otherwise I think there is a little-known software setting.
Could it be caused, for example, by the very process of using the JTAG port?

0841.BL_dev-project.zip

and what kind of diagnostics are available? I haven't been able to run another example that successfully resets GPIO1; as I said above, I built the Starterware example  "examples\beaglebone\gpio\gpioLEDBlink.c", that sets up GPIO1, but it doesn't get through the GPIO1 reset on that, either.

Hi 335Nov,

                Since the code runs on EVMSK, i dont think anything is wrong with the code.

Diagnostics - For your custom board your HW tean should have provided diagnostic code. You may need to check with them.

Also i tried to look at your IAR project configuration - seems the correct debugger is not selected. In the below image i see that simulator is selected. You need to select teh debugger you are using.

Regards

baskaran

In the .zip file I sent you, the debugger is set to "I-jet/JTAGjet"; it should be clear to you from my previous messages above that I know how to set that. I would not be getting the amount of things working that I did get working if I didn't have that set. This is a tricky problem, and needs to be escalated. I am deeply skeptical that it is hardware-related. You didn't provide any answers as to what kind of hardware problem can be so selective, as I asked.

If you don't find the debugger set to "I-jet/JTAGjet", just set it that way, and look for real issues. This problem doesn't seem to be so simple, and won't be solved so simply. Previously I needed things like basic setup, and setting the memory to load to only SRAM, not L3 OCMC RAM. Now the problem is trickier.

I have IAR ver 6.60.2.5507.

Hi 335Nov,

           I am not sure why the project settings shows as "simulator" when i imported your project.

Without knowing how your custom board is designed it will be difficult for me to provide suggestions. For better suggestions on HW side you may need to post your queries in "AM335x forum".

StarterWare forum is for support on StarterWare software package. If you can reproduce the issue with StarterWare code on the EVM's we support (EVM, EVMSK, beaglebone) i can help debug further.

If you want i can move this thread to AM335x forum so that you may get better assistance on HW side.

Regards

Baskaran

You might want to make sure your IAR is up-to-date. The GPIOs are internal to
the micro, and should not depend upon board design (I hope). I am not sure if
the problem is debugger setup or hardware (what in hardware can cause this given
the other things that I noted are working?), but both of the problems so far
have ended up being solved by debugger setup, the second one given knowledge of
what is going on in the micro, which is why the debugger people alone cannot
just give me the answer any more.

Since I am using Starterware, this is relevant to this forum. Also, you can't be
too narrow. Problems rarely fit into neat categories.
I am asking about this in the hardware forum.
This may require a double-pronged approach. The hardware questions I am asking
I am posting in the hardware forum.
Since this is a tricky problem, I am asking you to take more than a casual look
at this. You should try my setup on the EVM SK using the JTAG, not the USB, and
using the "I-jet/JTAGjet" debugger as in my setup attached, and actually using
an I-jet debugging pod from your PC. I don't have the JTAG on my EVM SK module.
I am attaching a bare-bones project that exhibits the problem: it sets up the
PER PLL and GPIO1 and calls the enable and reset, with code taken from
Starterware:
BL_gpio1.zip
The code is probably correct, as we have established. Is it only necessary to go
as far as the PER PLL setup to get this GPIO going?

2134.BL_gpio1.zip

Again: what is wrong with my debugger setup as contained in the attached
project?

For GPIO the clock is the only external it depends on. That's why i suspected clock earlier.

I don't have i-Jet/JTAGjet emulator with me to try your projects. Is it for legacy reasons that you chose i-jet emulator for your project?

Debugger - Still i am seeing that the debugger is set to simulator in my setup. I am not sure if something changes during export/import of projects.

I remember that you mentioned few days back you got the GPIO1 working for sometime and then it stopped working. - is that correct?

If that's the case you may want to try on different board. Probably your board has gone bad and the external oscillator not supplying required frequency ?.

Regards

Baskaran

I didn't choose the I-jet debugging pod; I am working with what I found when I
started on this job recently.
Debugger: just set it up correctly. Write down everything you set and let me
know.
It seemed like GPIO1 was resetting at first, but then it stopped happening. I
don't think anything went bad, because I have two new boards, and they both work
the same way.
The EVM SK has to be turned on before connecting it via USB. The code that I
have been trying works on it. For example, I don't have to restrict the memory
to SRAM only when loading to the EVM SK; the L3 OCMC is obviously set up, giving
another 64K of RAM in the micro. I suspect there is additional software setup
required for the GPIO reset to succeed that we're not being told about, that is
happening in the EVM SK, that is not included in the Starterware.
Is the GPIO enable and reset necessary? The IAR EVM SK example doesn't do it,
and GPIO1 blinks the LEDs fine. In the code that I'm building, GPIO0 works, and
I didn't do enable and reset; I just did the clock configuration.

...the clock is necessary to for the GPIO to work; something else in addition may be required for the *reset* to work.

I'm not loading anything to the EVM SK when debugging; I'm not using any
debugger script, so it seems that something is already set up in the EVM SK.
I had a conference call with technical people from TI, and they seemed to think
that something involving a .gel file had to be flashed to the micro's (the
microcontroller's, the XAM3359's) flash memory for some basic setup.
They indicated AM3358_StarterKit.gel in
C:\ti\AM335X_StarterWare_02_00_00_07 - Bootloader\tools\gel\
So what exactly needs to be flashed to the AM335, and how is it done?

335Nov --

Please review Startware wiki page for information on how to boot:

• http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing
• http://processors.wiki.ti.com/index.php/StarterWare_Getting_Started_02.00.XX.XX
• http://processors.wiki.ti.com/index.php/StarterWare_GPIO
• http://processors.wiki.ti.com/index.php/StarterWare_GPIO_V2

What I would really like to know is what goes on in the EVM SK after the power button is pressed. Even when there is no MicroSD card in the slot, the green light comes on and the mini USB port is enabled. What is set up to run in the EVM SK's micro when the power button is pressed as of when the module leaves the TI factory to be shipped to a customer?

This is what I was asking in the conference call.

...That is: What is set up to run in the EVM SK's micro when the power button is
pressed as of when the module leaves the TI factory to be shipped to a customer
(when there is no MicroSD card in the slot and nothing else except the power is
connected to the module)?

...and how about when the USB cable is connected to a laptop and the XDS driver is running?

Hello 335Nov,

  Could you please try toggling the LED inside of your boot loader (MLO). Your bl_main.c should look something like this:

3750.bl_main.c

Sorry, it doesn't work. I want answers to my latest questions, which can be seen above. Answering them will take an expert on the EVM SK.

Some repetition: see my earlier messages above in this thread.
I am finding that the TI Starterware bootloader runs on the EVM SK
( http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit ), but some things,
the initial WDT disable and the reset of GPIOs 1-3, won't work with the same
Starterware on my custom board that was modelled after the EVM SK. Also, I am
finding the L3 OCMC RAM in the XAM3359 set up already in the EVM SK when I
connect with the debugger, while it is not in my custom board; I have to keep my
code in the 64kB of SRAM in the XAM3359 unless I add code to set up the L3 OCMC
RAM. These things lead me to suspect that there is setup going on in the EVM SK,
after it is turned on, and before any Starterware is run, that I can't find
documented. I would like to have the source code for that setup so that I can
find out how it is really supposed to be done. Otherwise I would like to know
what is going on.

Hi 335Nov,

335Nov said:

Some repetition: see my earlier messages above in this thread.
I am finding that the TI Starterware bootloader runs on the EVM SK
( http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit ), but some things,
the initial WDT disable and the reset of GPIOs 1-3, won't work with the same
Starterware on my custom board that was modelled after the EVM SK

The MLO is the one doing this.  The ROM BL reads from initialized persistent storage (selected by boot mode) and copies the MLO into internal Ram. Our EVM is configured (thru boot mode pins -HW) to read the MLO from the SDCARD.

The MLO source code was provided in StarterWare ({install_root}/bootloader/src) and this is where any boot customization is done. There is a good chance that you may need to customize some of these files unless your HW is 100% same as our EVM.

The MLO does not come pre-loaded in our EVMs. The user needs to copy it themselves. The instructions are given here: http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flashing.

I believe that you confirmed that your application does work correctly on EVM-SK. So it’s clear that some modifications are required to port the bootloader to your board.

335Nov said:

Also, I am
finding the L3 OCMC RAM in the XAM3359 set up already in the EVM SK when I
connect with the debugger, while it is not in my custom board; I have to keep my
code in the 64kB of SRAM in the XAM3359 unless I add code to set up the L3 OCMC
RAM. These things lead me to suspect that there is setup going on in the EVM SK,
after it is turned on, and before any Starterware is run, that I can't find
documented. I would like to have the source code for that setup so that I can
find out how it is really supposed to be done. Otherwise I would like to know
what is going on.

This is where the GEL files are used. GELs are used during debug and are required when debugging.  They perform similar functions to the MLO with respect to configuring the device for the board specific components and operating conditions but also allow for quick testing of configuration changes.  Similar to the MLO, this needs to be adapted to your design.

The GEL file is needed if boot-loader is not used. Otherwise the boot-loader does all required configurations, and additional configurations are not required from the GEL file.

GEL files are used with debugger. With their specific emulator, a different type of GEL file (or equivalent emulator script) would be needed.

The GEL configuration runs automatically ‘on connect’ to setup everything needed for StarterWare to function correctly.

As I indicated previously, I am using the SAME debugger setup on my custom board
as on the EVM SK, with no GEL file, only changing the debugger driver between
"TI XDS 100/220" driver on the EVM SK module and the "I-jet/JTAGjet" driver on
my custom board. THERE IS NO DEBUGGER INIT SCRIPT OF ANY SORT. HOW MANY TIMES AM
I GOING TO HAVE TO KEEP TYPING THIS??
It is the MLO I am trying to develop. The things I noted: the WDT disable, the
reset of GPIOs 1-3, miraculously work in the EVM SK, along with the L3 OCMC
being already set up AFTER I TURN ON THE EVM SK, when I try to debug this
bootloader I am developing = MLO, which comes from the Starterware.
THERE IS SOMETHING GOING ON IN THE EVM SK BEFORE THE MLO/BOOTLOADER IS RUN, THAT
IS LETTING THE ABOVE WORK. IT IS NOT IN THE MLO/BOOTLOADER.
The differences are probably not in hardware, because all of the above are just
in the microcontroller, and the board probably has little to do with it.

I really want someone who knows what he is talking about, about the EVM SK, to
divulge what is going on when the EVM SK is turned on.

With no uSD card in the EVM SK, and no debug script (no GEL file, etc.), I can
connect via the debugger, and find the L3 OCMC set up already; the RAM from
0x40300000 to 0x4030FFFF is on and accessible. But that requires some setup. But
there is no uSD card in the slot and no debug script being run, just the EVM SK
turned on and using the Texas Instruments XDS100+RS232 V1.0 driver to connect
the debugger via the USB port. WHAT IS SETTING UP THE L3 OCMC RAM? If you don't
believe me, why don't you come to my company and see it for yourself, or try it
yourself with an EVM SK module of your own?

No GEL file, Dave, No .mac file, Dave. No debug script of any sort, Dave.