[etherlab-users] stack overflow

[Luigjes, Godert]

HI all,

I am evaluating a HBM CX27 EtherCAT data aquisition system.
It has, at least for me unusal way of configuring the PDO map.
Each input signal, and its corresponding data signal occupies
two 'ec_pdo_info_t' entries.

To clearify, 'ethercat cstruct' looks like this:

ec_pdo_entry_info_t slave_10_pdo_entries[] = {
    {0x6130, 0x01, 32},
    {0x6150, 0x01, 8},
    {0x6130, 0x02, 32},
    {0x6150, 0x02, 8},
...
    {0x6130, 0xc7, 32},
    {0x6150, 0xc7, 8},
    {0x61d1, 0x02, 64},
    {0x61d1, 0x03, 64},
    {0x61e1, 0x01, 64},
};

ec_pdo_info_t slave_10_pdos[] = {
    {0x1a00, 2, slave_10_pdo_entries + 0},
    {0x1a01, 2, slave_10_pdo_entries + 2},
    {0x1a02, 2, slave_10_pdo_entries + 4},
    {0x1a03, 2, slave_10_pdo_entries + 6},
    {0x1a04, 2, slave_10_pdo_entries + 8},
...
    {0x1ac8, 1, slave_10_pdo_entries + 399},
    {0x1ac9, 1, slave_10_pdo_entries + 400},
    {0x1aca, 1, slave_10_pdo_entries + 401},
};

As you can see it can handle loads of data signals.
The problem is that during configuration of the device
I get a stack overflow.

I have instrumented some code in fsm_pdo.c, showing the actual free stack space.

-- Function: ec_fsm_pdo_conf_action_pdo_mapping  stack free: 0x00001be0
-- Function: ec_fsm_pdo_conf_action_check_mapping  stack free: 0x00001b6c
-- Function: ec_fsm_pdo_conf_action_pdo_mapping  stack free: 0x00001b4c
-- Function: ec_fsm_pdo_conf_action_check_mapping  stack free: 0x00001b4c
...
-- Function: ec_fsm_pdo_conf_action_pdo_mapping  stack free: 0x0000006c
-- Function: ec_fsm_pdo_conf_action_check_mapping  stack free: 0x0000003c
-- Function: ec_fsm_pdo_conf_action_pdo_mapping  stack free: 0x0000001c
-- Function: ec_fsm_pdo_conf_action_check_mapping  stack free: 0x00000004
-- Function: ec_fsm_pdoBUG: unable to handle kernel paging request at 696c610a

There seems to be some recursion going on, eating the stack and crashing the application.


If the HBM is cold-started, it has no configuration and the code does not
go into recusion. It probably uses the escape route in
ec_fsm_pdo_conf_action_pdo_mapping() where the list_empty() exits the function.
If the application is restarted without a power cycle on the HBM unit
it enters the recursion and crashes.

For now I have a work around this problem. Default the SII-EEPROM does not have
'enable_pdo_configuration' bit set, in CoE details. When I enable this bit, the
code uses the escape in 'ec_fsm_pdo_conf_action_check_mapping' and exits via
ec_fsm_pdo_entry_start_configuration().

For now this seems to work. I have to double check if I get all my data.
At least the application does not crash anymore.

Godert Luigjes,
Software Engineer, Moog Inc.




Confidentiality Notice: This electronic mail transmission is intended for the use of the individual or entity to which it is addressed and may contain confidential and/or proprietary information belonging to the sender. If you are not the intended recipient, you are hereby notified that any disclosure, use, copying, distribution, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please notify the sender immediately by e-mail and delete the original message. Thank you for your cooperation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20150915/22e7c48e/attachment-0002.htm>