Lwip/DHCP failure on RM46 using halcogen 3.0.5

My only other guess also at this point is that I need to enable the interrupt for the EMAC driver.  But I don't see it anywhere in HalCoGen, so my assumption has been that it should be enabled by default, but....

Hi,

on a RM48HDK there is almost the same situatione here.

We are trying to build a halcogen setup as described in  http://processors.wiki.ti.com/index.php/HALCoGen_Ethernet_Driver_and_lwIP_Integration_Demonstration
(which is running proper - but no halcogen setup provided there) as well as in the video tutorial on ti-training.

Setup:

• halcogen 03.05.02
• ccs 5.4.0.00091
• lwip and other sources from the example

We are not able to generate apropriate hacogen setup which is needed for our further development.

As written in the previous post, code stucks in  while((*state != DHCP_BOUND) && (cnt--));

Can some one provide a valid halcogen configuration?

Thanks a lot

Andreas

Things we tried:

• pll was set to 160MHz in the example project -> changed in our project
• PinMux: Interface-type MII (from the video tutorial) as well as G3 and V5 Pin
• EMAC: physical adress to 1 (example above)
• Setup Interupts: VIM RAM:
  • 77: EMACCore0TxIsr
  • 79: EMACCore0RxIsr

  Also enabled VIM Channel 77 and 79 (tried both IRQ and FIQ)

Hello,

We apologize for the delay of this answer.  The forum question did not get assigned to the right owner.

I am forwarding to the right owner and hopefully we can get this information.

Overall, my experience with TI tools, examples, and halcogen has been so beyond frustrating that I've on repeated occasions wanted to hulk smash the HDK (With lots of collateral damage of the laptop and anything with a TI tool installed) and go to a different processor.  I will exclude the profanities hurled at TI as well.

I honestly don't remember what it was that we did that fixed it.  There were so many issues it wasn't funny.  Make sure your MDIO and MDCLK IO's are set properly and actually twiddling with a scope.  Make sure your interrupts are being called.  I put in a serial port debug for whenever I received a packet.  Also enable interrupts with _enable_IRQ().  The biggest issue I've found is that if you go to lwiplib.c where it's stuck in that while loop, there should be some handling for an interrupt.  For our custom board, I eventually found how to set RMII mode, and at the same time ran iommUnlock(), iommMuxEnableRmii();, etc.  They're in lwip_main_init.c.  Physical address is set to 0 on my current halcogen config.

I also had to re-write the interrupt handler so that it was reentrant.  If you're running anything with debug, or doing something complex, you can get an interrupt while you're handling your emac packet interrupt, and then the system spins out of control.  Instead, whenever I get a packet and the interrupt handler is called, I increment a variable.  My main.c has a while(1) loop that checks that status of those variables, and if != 0, it executes the appropriate interrupt handler.  This way you can't get an interrupt while processing an interrupt (lots of ways to fix this issue).  TI is the only one it seems that handles packets in an interrupt routine, and I think I know why.  I'll keep that opinion to myself.

  </hate>

Good luck!

Oh, and if you get it working, I would also suggest upgrading to lwip-1.4.1.  It fixes some issues from the 1.3.x version TI uses, which is waaaay outdated.

Hello Martin,

thanks for replying. Yes, we would  port on lwip 1.4.1 - later encapsulated in a FreeRtos than.
We will look on your detailed suggestions soon.

Hopefully Henrys forwarding will also provide some news.

Regards

Andreas

Folks,

We definitely regret eliciting the 'Hulk smash' feelings / frustration,  and please don't interpret this post as debating whether or not the demonstration project has issues or not.

But I do think it's important to be realistic with expectations around the example project HALCoGen_Ethernet_Driver_and_lwIP_Integration_Demonstration.   This really is just an example project;  there isn't a dedicated development team behind it.  Our ability to support (through forum) is limited right now by expertise.  And not having a development team behind the example as you would a 'product' means one shouldn't expect a deterministic schedule for updates / improvements.

The example is still very useful in the sense that without investing money in a commercial solution you can evaluate the EMAC on the HDK.  And if you are comfortable with the open-source support model you could continue development on your own using this as a starting point.

But this may not be the best solution for every use case.  If dedicated support and deterministic development schedules/roadmaps are important we can really only recommend looking at one of the commercial offerings at this time.   We have a list of RTOS providers here: http://www.ti.com/lsds/ti/microcontroller/safety_mcu/rm4_arm_cortex-r4/tools_software.page#software . Most of these partners have TCP/IP stacks available and support Hercules.  We also expect to see TCP/IP stacks with safety certification capability available from multiple vendors in the near future - very important given the focus of the Hercules product line.   

Please take a look at these options as well.  Also if you have an RTOS or middleware provider that you would like to see on this list that isn't already, please post that.  We do actively work with these companies to make sure that they support Hercules and this is an ongoing activity.  

Thanks and Best Regards,

Anthony

Hi Anthony,

Thanks for the reply.  Yeah, as much as I would like TI to do my job for me, I know I can't expect that!  I would happily release my version of what we've developed, however there are two main issues...

1) I'm under NDA to an extent, and being paid for the work, so it would have to be cleared with the client.

2) I'm an EE by trade, not a software developer.  I know enough and how to get things working from the example, but when it comes to "correcting" the HDK example and producing *good* code, I'm not your guy, nor is my code.  It works, but it's ugly.  I also don't know that it is truly "Correct" (IANACE).

That said, if I could make one suggestion for the LWIP demo, it would be to make it complete so that it can at least be reproduced with current tools.  I understand the resources might not be there for it and as a result, there might be a *LOT* of demos that would need similar updating, but the big 'hulk smash' moments came when I found I had to do something with halcogen that isn't discussed anywhere, e.g. VIM RAM setup and the like, just to get to the starting point of playing with the demo.  If I modify it outside of the scope of example (e.g. where reentrancy becomes an issue), that's my fault, not yours :)

All my other 'gripes and frustrations' have already been communicated via private messages, so I hope they help you at least to improve the tools.

My HalCoGen config, however, does not contain any proprietary information, so I'm more than happy to share it.  For all those who might look at it, it is *NOT* for an HDK, but for a custom board using RMII, but it might make for a good comparison.

3107.BR_AASV_HalCoGen.zip

Cheers,

Martin

Hi Martin,

Thank you for your understanding, private feedback, and your nice thought of sharing your work to the e2e community to help others while we are working internally to resolve this HDK example issue for Halcogen.  We truly appreciate this.

Thanks you again...

Hi all,

thanks to Martins input we got the emac demo running with a halcogen 3.05 setup for a RM48HDK

The files attached here, comparing to the example setup here the UART is running with 115200Baud 1 Stopbit

As Martin mentioned I think the main issue is not to use any other interrupt.

Martin is also right with his comment about the interrupts, running the complete stack there. The lwip-demo is only a demo so Anthony is also right but:

It would not harm if ti gives a hint not using newer halcogen version (missing in the web-site and the video tutorial as far i recogniced).

Would save a lot of time :-)

Steps to Build:

• delete old halcogen -include and source -folder
• run code generation
• rename all unit8_t and uint32_t to uint8 and uint32 in the lwip sources
• dont forget to add in sys_main.c :
  /* USER CODE BEGIN (2) */
  extern void EMAC_LwIP_Main (uint8 * emacAddress);
  /* USER CODE END */
  
  void main(void)
  {
  /* USER CODE BEGIN (3) */
      EMAC_LwIP_Main (emacAddress);
  /* USER CODE END */
  
  
  

I seem to recall adding hal_stdtypes.h to the user comments sections in a few places so that the halcogen source would compile.  I wanted to make it so that I didnt have to edit any of the halcogen files every time I regenerated the code.