make examples fails - too many arguments in call to "Create_Restricted_Task_Sequential"

[mhanuel26]

Hello Stephane,

I was building the examples using the make file when I got this error no matter the example used.

_ada-enet$ make ping arm-eabi-gnatmake -XBUILD=Debug -XBUILD_RTS=Debug -Pping -p -cargs -mno-unaligned-access Compile [Ada] ping.adb receiver.ads:33:04: too many arguments in call to "Create_Restricted_TaskSequential" gprbuild: compilation phase failed Makefile:8: recipe for target 'ping' failed make: [ping] Error 5

I understand the problem is in receiver.ads

   task Controller with
     Storage_Size => (16 * 1024),
     Priority => System.Default_Priority;

but do not know what is the problem with arguments.

the library build successfully using

arm-eabi-gnatmake -Panet_stm32fxxx -p

I notice that the sources of Ada_Drivers_library are somehow different from the repo here , the command make checkout use commit "751f0489dffe763a75ae4df709889cae28fe9b1e" for Ada_Drivers_Library and commit "5cca89013958a14831ac029c60636c7c56bf8f5f" for Ada_Drivers_Library/embedded-runtimes , If I want to uses the latest development commit, how can I proceed?

I will appreciate your comments,

[stcarrez]

Ada Core changed again their organization of GNAT projects. It does not compile anymore if you use the latest Ada Drivers Library. Fighting with their GNAT project is a mini-nightmare. I'll have a look anyway.

I've never seen the problem you mention. Which compiler are you using? (I've not yet installed the GNAT 2017 arm version)

[stcarrez]

It seems that the GNAT projects from Ada Drivers Library are not longer compatible with the GNAT 2016 arm compiler. There is the new definition:

for Create_Missing_Dirs use "True";

which is nice but not compatible with GNAT 2016...

[mhanuel26]

Hi,

I am using the 2017 version. I actually tried to build a project that uses the task creation for the latest development Ada Drivers Library, and it builds Ok, the project is called Hello_World_Tasking_F469Disco. But when I try to compile the same project under your ada-enet repo it produce the aforementioned error.

I might be wrong but I was suspecting one of the difference that might be affecting is that the embedded_runtimes of Ada Drivers Library seems to be empty, I understand it works since the installed 2017 gnat include the ravenscar under the arm-eabi folder. The same project in you repo seems to have the config.gpr pointing to use static files within the repo

-- Include the run-time project files to have them compiled _with "../../embedded-runtimes/ravenscar-stm32f469disco/ravenscar_build"; with "../../embedded-runtimes/ravenscar-stm32f469disco/runtimebuild";

Please let me know what would you suggest is better, if try to fix the issue to be compatible with 2017 version or keep using the environment that works for you.

By the way you didn't mention which gnat version works for you.

Please let me know and thank you for your comments,

[stcarrez]

I was using GNAT 2016.

I've installed GNAT 2017 and switch to that compiler since Ada Drivers Library no longer works with GNAT 2016.

I've managed to update the project and the commit https://github.com/stcarrez/ada-enet/commit/c33b7d505f02f7aa2b96dc6cdabf607c962564c3 fixes all this with the latest Ada Drivers Library.

[mhanuel26]

Hello Stephane,

Thank you for the updating,

Now it compiles and I can build the project.

I am just having problem with any of the demo projects, I am working on the stm32f769_discovery board, when I load i.e. the echo demo, the program write to LCD but fails to get DHCP, it actually reset after a few seconds.

When trying to debug using GPS I got on debugger console

Program received signal SIGTRAP, Trace/breakpoint trap. 0x08029866 in system.semihosting.put ()

I have disable the DHCP by commenting the line Demos.Dhcp.Process (Dhcp_Deadline);

and it doesn't cause the SIGTRAP.

Do you know how to enable a virtual COM to print message during debugging, I can place breakpoint but then I cannot go by STEP using F5, if I do it I get

(gdb) step 0x08028d64 in __gnat_irq_trap ()

Another thing I was wanting to try was to disable DHCP and use static IP, I saw this commented lines in demo.adb

-- Ifnet.Ip := (192, 168, 1, 2); -- Ifnet.Gateway := (192, 168, 1, 240); -- Ifnet.Dns := (192, 168, 1, 240);

Should I try it by un-commenting them and commenting the DHCP calls?

Please let me know your thoughts,

Appreciated!

[mhanuel26]

Hi Stephane,

I have confirmed the problem is with DHCP code, I have commented the DHCP in echo.adb

-- Demos.Dhcp.Process (Dhcp_Deadline);

and enable static IP in demos.adb

  --  Static IP interface, default netmask and no gateway.
  Ifnet.Ip := (192, 168, 1, 69);
  Ifnet.Gateway := (192, 168, 1, 1);
  Ifnet.Dns := (192, 168, 1, 1);

-- Dhcp.Initialize (Ifnet'Access);

Then I can ping and echo command with socat works.

Please let me know if you have any clue about the DHCP code that cause cpu to reset.

Thank you,

[stcarrez]

When you run the program through gdb there are some nasty issues due to interrupts.

• When you first attach (Run), sometimes an interrupt is dispatched before the Ada runtime has initialized everything. You end up with a crash. I often have to push the reset button on the board after the attach (Run) to solve this.
• When you STEP you can receive an interrupt because a network packet has arrived. The debugger then stops at beginning of the interrupt handler and displays the __gnat_irq_trap () function. I have no solution for this, except avoid using STEP when this happens and use a breakpoint. Sometimes you can just CONTINUE to skip the interrupt. Sometimes, if your board receives too many packets, it's impossible. You could unplug the Ethernet cable to avoid that.

As for the static IP configuration, this is the code I was using when I was not having the DHCP. I'm glad you found it to use it on your side.

The DHCP should work but I suspect that it receives a DHCP packet that is not handled correctly. For now, I have no clue. What would help me is if you could get a network trace somewhere with wireshark or tcpdump.

[stcarrez]

I found the problem with the DHCP implementation. We can receive several IPv4 addresses for several DHCP options and it was not handled. The packet extraction and analysis lacked a number of checks to make sure we check within the received packet data.

I've fixed all this (see commit).

[mhanuel26]

Very nice @stcarrez , thank you very much. Cheers,