Connecting Ethernet to F28M35 ControlCard Vers 2.0 Causes Reset

Hi Grant,

Did you go through this workshop doc?

4431.F28M35x_Workshop_2-0.pdf

Regards,

Gautam

I have it and have read most of it.  Was there a particular section that you feel I should read that addresses the problem I described above?

Please try using the original example with this updated GPIO setup code and report back.

2476.set_pinout_f28m35x.c

6710.set_pinout_f28m35x.h

Regards,

Gautam

Gautum,

The GPIO setup should be fixed in the release I did last month.

Grant,

I'm curious if there is an interrupt occurring.  Here's what I'm thinking:

Application is running fine.

You plug in ethernet cable.

Ethernet causes an interrupt.

CPU goes to service interrupt but because this is the blinky example, nothing is plugged in to function as a handler.

CPU faults and resets.

I would take Gautum's advice and try one of the stock ethernet examples in order to make sure there are no weird electrical issues going on.  If that functions correctly, try plugging in some dummy function as an interrupt handler for ethernet in the blinky example.

BR,

The modified set_pinout files did not fix the problem. I created a new folder (v202A), copied the files from Gautum to MWare/board_drivers,  imported the example project again.  Connecting to LAN still crashes the controlCard.

As I said earlier (first post), the ethernet works fine, since I have been happily developing a web server based off LWIP using the same controlCard for the last month.  That was what help reveal the problem.  I was ready to add the C28 functionality and could not get blinky running with the project, because it requires an Ethernet connection .  I then stepped back and tried to run the default blinky project with the LAN cable and was not able to.

Grant,

with the LAN connected can you check the boot mode pins, one of the boot mode pins is muxed with the EMAC pins, I guess the GPIO43. If that is getting pulled LOW on power up with LAN cable connected then on REV0 of the device this would default to FLASH but on the latest TMS version of the Silicon (including REVB) this would enter the BOOT-TO-OTP.

Now, on F28M35x REVB version of Si, user can change the boot mode pins by programming OTP...this is explained in the forum post http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/312626.aspx

Hope this helps.

Best Regards

Santosh

or if you don;t want to change the boot mode pins then you could program a 'branch to flash entry point" instruction at the boot-to-otp entry point. This way the Boot-to-OTP would also effectively end up in flash. But you have to confirm if that GPIO43 is (boot mode) is the problem.

Best Regards

Santosh Athuru

If booting and Ethernet pins were conflicting, why was I able to run LWIP from flash?  Still, I will take a look and try to digest the more complicated muxing of the GPIOs of the F28M35x -- I do not entirely understand how that can be a cause  since all the other Ethernet examples boot fine.  The problem seem to arise only when the c28x comes into the picture.  

Adding to my thoughts above -- I said in the first post:

However, when I plug in a ethernet cable (connected to a LAN) to the controlCard while blinky is running,  the LEDs freeze.

This says I can get the blinky  to crash after it has booted.  Again, I am not familiar with the intricacies of the F28M25x boot process, but if this were a problem, it seem like none of the TI Ethernet examples would work.  Can the boot pins be re-purposed after boot? 

Grant,

Yes, the boot pins can be re-purposed after boot, and from your description of the issue I don't think the boot pins are at fault here.

So when you plug the ethernet cable in the C28 continues to run, but the M3 resets...If you halt the M3 is there a particular address where it seems to be stuck at?

BR,

Grant,

yes.. the boot pins can be re-used for different things after boot. This might not be a problem with the boot pins, lets see.

How sure are you about "LEDs freeze" == application crash? did you try to run the application with debugger connected and then plugin the LAN cable, after the LEDs freeze and pause the application in CCS debugger and see where the PC is at? what happens if you do a debug reset, restart and run with the LAN cable still connected? and what happens if you do a debug reset and run with the LAN cable still connected.

Grant10435 said:

However, when I plug in a ethernet cable (connected to a LAN) to the controlCard while blinky is running,  the LEDs freeze.

Best Regards

Santosh

I programmed the chip using the debugger and leave it connected.  In the Debug tab, both the M3 and C28 have a status message that says (Running), both LEDs are blinking.  I plugin in the Ethernet, both LEDs stop blinking (are constantly on).  The M3 Debug status toggles quickly between (Running) and (In Reset - A Reset Occurred On The Target).  The C28 says (Running).  

If I pause the M3,I get Cortex_M3_0: Trouble Halting Target CPU: (Error -2062) .... so I was not able to pause on a particular line of code.

If I Pause the M3, press the CPU Reset button, followed by the Reset button and Resume, the M3 LED turns on and stays on (not blinking).  If I do the same with the C28, then the C28 LED turns on and stays on (not blinking).

If I unplug the Ethernet cable, magic, both LEDS blink, both CPU status says (Running). 

Grant,

I will try this on my control card as well (earliest possible is Monday next week). Can you answer below

> what are the boot mode jumpers set to on your control card? This will tell us if there are any stale interrupts enabled in the bootROM that the application doesn't care of; usually the applications re-initialize NVIC, but blinky example is simple so it doesn't. If boot mode pins are all HIGH then bootROM shouldn't enable any of the interrupts, but if doing serial or EMAC boot then boot ROM enables a GPIO edge interrupt (I think PA0, UARTRX) and a systick interrupt.

> What is the reason you are doing this experiment, now, since blinky example doesn't have any EMAC code what is the need of connecting the LAN cable while booting to LED blinking example? It is not working, it is definely bad for sure and we will get to the problem, but wanted to understand if you came to this to debug tracking some other error/symptom?

> Did you scope XRSn pin to see if there is an activity on XRSn when you plug-in the LAN cable or remove the LAN cable.

> On the below, while the LEDs are frozen are you able to pause the M3 second time and step through the code to see if program is still in the application loop writing to the GPIO registers? This will tell us if JTAG gets doomed as well.

Grant10435 said:

If I Pause the M3, press the CPU Reset button, followed by the Reset button and Resume, the M3 LED turns on and stays on (not blinking).  If I do the same with the C28, then the C28 LED turns on and stays on (not blinking).

> can you change line 114, 122 and 132 (Turn off LED to below) in your blinky_m3.c as below respectively and rebuild, reload and run?

114->GPIOPinWrite(LED_1_BASE, LED_1_PIN, ~LED_1_PIN);
   

        //
        // Turn on the LED.
        //
 122->       GPIOPinWrite(LED_1_BASE, LED_1_PIN, ~LED_1_PIN);

        //
        // Turn off the LED.
        //
   132->     GPIOPinWrite(LED_1_BASE, LED_1_PIN, LED_PIN_1);

Best Regards

Santosh

> what are the boot mode jumpers set to on your control card? This will tell us if there are any stale interrupts enabled in the bootROM that the application doesn't care of; usually the applications re-initialize NVIC, but blinky example is simple so it doesn't. If boot mode pins are all HIGH then bootROM shouldn't enable any of the interrupts, but if doing serial or EMAC boot then boot ROM enables a GPIO edge interrupt (I think PA0, UARTRX) and a systick interrupt

All switches on SW1 are in the down position.  

> What is the reason you are doing this experiment, now, since blinky example doesn't have any EMAC code what is the need of connecting the LAN cable while booting to LED blinking example? It is not working, it is definely bad for sure and we will get to the problem, but wanted to understand if you came to this to debug tracking some other error/symptom?

I have been developing an http server based on LWIP, which runs solely off the M3.  I started to integrate the second core, which I thought would be straightforward, but my program kept resetting.  As a sanity test, I tried blinkly light and that too was resetting.   It took a few days to realize that the reset only happens when the Ethernet cable is connected.

> Did you scope XRSn pin to see if there is an activity on XRSn when you plug-in the LAN cable or remove the LAN cable.

I can get that information to you by Tuesday.

> On the below, while the LEDs are frozen are you able to pause the M3 second time and step through the code to see if program is still in the application loop writing to the GPIO registers? This will tell us if JTAG gets doomed as well.

JTAG is still good.  I messed around a little more for you and put a break at the start of main.  I am not able to execute past SysCtlClockConfigSet which is is the third line of code after main.

> can you change line 114, 122 and 132 (Turn off LED to below) in your blinky_m3.c as below respectively and rebuild, reload and run?

Did what you said, no change, which was expected since I can't get very far into main before a reset.

Grant,

based on below, it looks like the device is waiting for PLL LOCK  STATUS to set. Can you check if SYSPLLLOCKS is set in the PLL registers at this point? or can you modify the blinky main() to comment out the call to the SysCtlClockConfigSet function in your main and see if it works.

when you program blinky_m3 on M3 are you programming bliny_c28x on the C28x core or is it running something else?

Grant10435 said:

JTAG is still good.  I messed around a little more for you and put a break at the start of main.  I am not able to execute past SysCtlClockConfigSet which is is the third line of code after main

Does this happen on more than one board with REVB?  I was able to find a cpontro lcard with REVB Silicon but it is Release 1.0, can you confirm if yours is Release 2.0 ? is it printed as release 2.0 on control card?

regarding below, can you give an idea on what C28x application here is doing? is it configuring something? we will get to this once we figure out above

Grant10435 said:

I have been developing an http server based on LWIP, which runs solely off the M3.  I started to integrate the second core, which I thought would be straightforward, but my program kept resetting.  As a sanity test, I tried blinkly light and that too was resetting.   It took a few days to realize that the reset only happens when the Ethernet cable is connected.

Best Regards

Santosh

I am running only blinky_dc_c28 and blinky_dc_m3.

The register SYSPLLSTS reads 0x00000001 (Locked), does matter if I comment out any lines of code, its always that same.

If I comment out the line 

SysCtlClockConfigSet(SYSCTL_USE_PLL | (SYSCTL_SPLLIMULT_M & 0xA) |SYSCTL_SYSDIV_1 | SYSCTL_M3SSDIV_1 | SYSCTL_XCLKDIV_4);

I am unable to debug pass

IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH);

If I disconnect the debugger, power reset, boot standalone, both LEDS blink slower than before. If I plugin the Ethernet cable it still blinks (a first).

If I also comment out 

IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH);

I can get both LEDs to blink in debugger mode. Connecting the Ethernet has no effect. But if I try standalone, only the M3 LED blinks.

Attached a pictured of my controlCard.  Says Release 2, silicon is RevB.

Grant,

Thanks for your response.

I tried this on release 1.0 control card, with REVB Silicon and it worked just fine. I plugged in an Ethernet cable while the LEDS are blinking and also had the cable plugged in and powered up the board. I couldn't reproduce the problem.

I used the blinky dual core example from the latest control suite, before building the blinky, I recompiled my dirverlib (under mware) so the M3 project uses the latest driverlib and I had to add _STANDALONE as one of the predefined symbol on M3 project properties.

I'm trying to get a release 2.0 control card to try it. 

Regarding your responses...

The SYSPLLSTS status shows LOCKED so the SysCtlClockConfigSet function shouldn't get stuck. Did you try stepping in (you might have to point to the sysctrl.c in the mware/driverlib project to do source level debugging on driverlib funcs) the function to see why it is getting stuck there?

You are not able to debug past the IPCMtoCBoot function because that function is waiting for a response from C-Boot ROM. But you don't have C-boot ROM running on C28x. However that's fine because you confirmed that both the LEDS are blinking fine when powered up in stand alone mode irrespective of Ethernet cable being connected or not.

So form your results can we conclude that  "SysCtlClockConfigSet" function is the problem when Ethernet cable is plugged in?

Best Regards

Santosh

Santosh,

Thanks for testing out the problem on your end. I am just checking to make sure  that you connected  end of the cable to a switch or a router.  If you are able to get the version 2.0 board working, I will get another control card on order.  Disabling SysCtlClockConfigSet made blinky light work in STANDALONE only.  

I will mess around to SYSPLLSTS this evening. Thanks for all you help, seem that we are getting somewhere.

Grant,

yeah, Brett is helping me get a release2.0 control card, could be anytime now.

on ControlCard Release 1.0(M35x REVB), I connected the cable to the office LAN network (there would be constant traffic). The green LED on the RJ45 is blinking showing there are packets incoming. The RED LEDS labeled LD2 and LD3 on the control card are blinking as well.

Grant10435 said:

 Disabling SysCtlClockConfigSet made blinky light work in STANDALONE only.  

regarding above, it would work with debugger connected as well, you have to follow the below steps.

> Program flash on both the cores

> disconnect CCS

> power off and power ON (you would see the LEDS blinking) - this is stand alone

> now connect CCS

> reset both the cores

> run C28x - this would let the C28x boot ROM run and it would be waiting for IPC command from M3 application

> run M3...it would go to M3 application and send the IPC command

>  both the cores should be blinking.

One thing to remember is when you program flash using CCS flash plug-in the Flash plug-in configures PLL in it as well. That shouldn't cause any problem at all, because re-locking should work always.

Best Regards

Santosh

Santosh,

Those steps worked like a charm.  I was able to program both cores, debug them, and still connect an Ethernet cable.  So to confirm, SysCtlClockConfigSet seems to be the root cause – removing it also causes the LEDs to blink slower. 

I went through the forums, and there is very little about SysCtlClockConfigSet .  I am really curious to see if you are able to repeat my problem with version 2.0 card.  When you ran the version 1.0 card, did you keep the call to SysCtlClockConfigSet?

Grant,

I tried with Release 2.0 control card and it worked. No problems plugging or unplugging the Ethernet cable, the LEDs were blinking. I set up my Release 2.0 control card same your control card (in picture above).

can you try on a different release2.0 control card?

Best Regards

Santosh

Well, the results of that test were a little disappointing :( .  I will get the second board on order and let you know the results.

Yeah, I began suspecting power by end of Friday and I tried powering my board with USB and it still worked. Glad you were able to reach a solution, this is a learning for both of us.

Feel free to post any more questions/suggestions you have onto this forum.

Best Regards

Santosh