Problems with wip_drvIsrSubscribe with the 2.32 openAT Suite

[mosipov]

Hello,

I’ve upgraded my Fastrack Supreme 10 (FSU004) to the latest openAT Embedded Software Suite 2.32(firmware R 7.42/openAT 6.32/WIP 5.30/LUA 2.0):

at+cgmr
R7.42.0.201003050914.FSU004 2131816 030510 09:14
OK

I’ve built my application (based on fastrack_ethernet and lua_intearctive samples from previous releases)
and during ethernet driver initialization I got an error (MAC address was fetched from eeprom correctly):

at+cfun=1ý
OK
+MAC: “0021C900071A”
[ENC28J60] register: SPI=2 CS=00003023 EXTINT=0
[ENC28J60] RST=00003013 PWR=00003014
[ETHER]: open: -> DISCONNECTED
[ENC28J60] init
[ENC28J60] mac address: 00:21:c9:00:07:1a
[DRVISR] cant subscribe to irq: -5
[ENC28J60] irq subscribe failed: -5
[ETHER]: start: -> failed to start interface: -26
cannot start bearer: -29

Actually The problem is with call wip_drvIsrSubscribe()
it fails with the error -5:

/* installs interrupt handler */
dp->isr_handle = wip_drvIsrSubscribe( (wip_drvData_t *) drvp,
drv_intr,
dp->extIntId,
WIP_DRV_IRQ_TRIGGER_FALLING_EDGE);
if( dp->isr_handle < 0) {
wip_debug( “[ENC28J60] irq subscribe failed: %d\n”, dp->isr_handle);
goto failure;
}

According to Manual, this error means that

ADL_RET_ERR_NOT_SUPPORTED The Real Time enhancement feature is not enabled on the embedded module

Note:
The Real Time Enhancement feature state can be read thanks to the AT+WCFM=5 command
response value: Please refer to the AT Commands Interface guide 1 for more information.
Note: Please contact your Sierra Wireless distributor for more information on how to enable this feature on
the embedded module

But, in my understanding, this extended commercial feature is enabled (bit 4 is set)

at+wcfm=5
+WCFM: 00000471,0
OK

With the open AT Software Suite release 2.21 (firmware 7.3.0.a.00/openAT 6.21/WIP 5.10/LUA 1.1.0)
I didn’t experience such problems.

Could you please provide me the hint what’s going on?

[TriGGeReD0]

Hi,

All that needs to be done is that you need to add the following lines into your code:

const u32 wm_apmIRQLowLevelStackSize = 1024;
const u32 wm_apmIRQHighLevelStackSize = 1024;

This defines the size of the low and high level stack to be used for the IRQ service. This is not in any documentation I have seen and I also struggled with it for a long time.

P.S. I know that this post is very old but it is for future reference.

Tyrone

[awneil]

@TriGGeReD0

This is not in any documentation I have seen and I also struggled with it for a long time.

Oh yes it is:

@ADL User Guide for Open AT® OS v6.21

3 API
3.1 Application Entry Points Interface
ADL supplies Application Entry Points Interface to allow applications to define the generic settings of the application tasks and contexts.
The application will have to define its entry points settings using the adl_InitTasks table. Each line of this table represents a task, which is characterized by the following parameters:
• the task entry point, called at the Wireless CPU® boot time, in the priority order
• the task call stack size
• the task priority level
• the task name
If the application wishes to use the IRQ service, it will also have to define the call stack sizes for it low level (adl_InitIRQLowLevelStackSize) and high level (adl_InitIRQHighLevelStackSize) interrupt handlers.

(my emphasis)

It’s also in the other versions of the ADL doc - but that’s the first one I found that allowed copying the text!

However, it is another example of how unhelpful SiWi’s error codes are.

See: Wip_berr_gprs_failed - #2 by awneil
And: Header-not-present result still unhelpful
And: Documentation Unhelpful/Misleading: WIP_BERR_OK_INPROGRESS

[TriGGeReD0]

Hmmm ok so it is in the documentation but it is hardly the thing you are looking for when seeing an error code like that.

Note to anyone wanting to use Ethernet with these CPU’s:

AVOID IT AT ALL COSTS. The quality of the Ethernet driver and documentation surrounding it is appalling to say the least.

[awneil]

You’re right - it isn’t mentioned anywhere in the WIP documentation.

I guess the WIP doc just assumes that you’ll realise that the driver is using IRQs, and that you’ll be familiar enough with using IRQs to know that they need the stacks defining?

But I don’t think it’s a reasonable assumption - especially as there is no guidance on what stack sizes will be required!

Unfortunately, this is typical of Wavecom documentation (inherited by SiWi).

[mosipov]

Hi Tyrone,

Thank you for your feedback.

All that needs to be done is that you need to add the following lines into your code:

const u32 wm_apmIRQLowLevelStackSize = 1024;
const u32 wm_apmIRQHighLevelStackSize = 1024;

In my understanding, since around 6.31 openAT release one have to define these stack sizes via “Code generation parameters” form, which will generate “generated.c” defining these parameters:
For example mine generated.c contains:

// Application version definition
const ascii adl_InitApplicationVersion = “2.01”;
// Low level handlers execution context call stack size
const u32 adl_InitIRQLowLevelStackSize = 1024;
// High level handlers execution context call stack size
const u32 adl_InitIRQHighLevelStackSize = 1024;
// Application tasks prototypes
extern void mainTask ( void );
// Application tasks declaration table
const adl_InitTasks_t adl_InitTasks =
{
{ mainTask, 24576, “mainTask”, 1 },

{ 0, 0, 0, 0 }

};

The bad thing with this generated.c that it sometimes regenerated and losts the previously entered parameters - see The Task Table becomes empty when changing Memory Type.
Maybe that was the reason of my problem with ethernet.

Kind regards,
Maxim.

[awneil]

@mosipov

In my understanding, since around 6.31 openAT release one have to define these stack sizes via “Code generation parameters” form, which will generate “generated.c”

No, you don’t have to do it that way; that’s just the way that M2MStudio provides - you may choose to use it, or not.