Senthil Kumar a écrit :
> https://gcc.gnu.org/bugzilla/
>
> You would need a reduced testcase/preprocessed file (xxx.i obtained by
> compiling with -save-temps) to debug the issue - the .S file isn't
> useful to debug the compiler.
Done.
https://gcc.gnu.org/bugzilla/
You would need a reduced testcase/preprocessed file (xxx.i obtained by
compiling with -save-temps) to debug the issue - the .S file isn't
useful to debug the compiler.
Regards
Senthil
On Thu, Jun 24, 2021 at 11:36 AM BERTRAND Joël
wrote:
>
> Senthil Kumar a écrit
Senthil Kumar a écrit :
> This looks like a miscompilation to me.
...
> What version of the compiler are you using? Can you make a reduced
> testcase containing just the LDL_MAC_otaa function?
Just a question. Should I fill a bug report ? And if yes, where ?
Best regards,
Senthil Kumar a écrit :
> What version of the compiler are you using?
I have seen this bug with Debian compiler :
hilbert:[~] > avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
This looks like a miscompilation to me. Specifically, in good_2.S, you have
a318: f6 01 movw r30, r12
...
a33c: e3 50 subi r30, 0x03 ; 3
a33e: ff 4f sbci r31, 0xFF ; 255
a340: 01 90 ld r0, Z+
a342: f0 81 ld r31, Z
a344: e0 2d mov r30,
David Brown a écrit :
> On 23/06/2021 10:37, BERTRAND Joël wrote:
>
>> In bad.S, self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, ) gives :
>> a340: 68 01 movwr12, r16
>> a342: ff e4 ldi r31, 0x4F ; 79
>> a344: cf 1a sub r12, r31
>>
This part
> a340: 68 01 movwr12, r16
> a342: ff e4 ldi r31, 0x4F ; 79
> a344: cf 1a sub r12, r31
> a346: fe ef ldi r31, 0xFE ; 254
> a348: df 0a sbc r13, r31
> a34a: e3 50 subir30, 0x03 ;
On 23/06/2021 10:37, BERTRAND Joël wrote:
> In bad.S, self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, ) gives :
> a340: 68 01 movwr12, r16
> a342: ff e4 ldi r31, 0x4F ; 79
> a344: cf 1a sub r12, r31
> a346: fe ef ldi r31,
Comparaison between good.S and bad.S.
Good.elf is compiled with :
app_handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, );
instead of bad.elf that is compiled with :
self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, );
in enum ldl_mac_status LDL_MAC_otaa(struct ldl_mac *self)
Some news.
In lorawan/ldl_mac.c is defined LDL_MAC_otaa :
enum ldl_mac_status LDL_MAC_otaa(struct ldl_mac *self)
{
enum ldl_mac_status retval;
union ldl_mac_response_arg arg;
LDL_PEDANTIC(self != NULL)
if(self->ctx.joined){
retval = LDL_STATUS_JOINED;
Trampas Stern a écrit :
> Also when you print out the size in the make file, how much SRAM does it
> indicate your program is using?
AVR Memory Usage
Device: atmega1284
Program: 101324 bytes (77.3% Full)
(.text + .data + .bootloader)
Data: 6890 bytes (42.1% Full)
(.data
Also when you print out the size in the make file, how much SRAM does it
indicate your program is using?
On Tue, Jun 22, 2021 at 2:10 PM Trampas Stern wrote:
> So I would recommend that you put in the ASSERT for the LDL_PEDANTIC()
> macro.
>
> Secondly, you need to be careful with PROGMEM, that
So I would recommend that you put in the ASSERT for the LDL_PEDANTIC()
macro.
Secondly, you need to be careful with PROGMEM, that is with AVR being a
Harvard machine you can burn up SRAM quickly by not using PROGMEM for
constants. For example with the LDL library you need to be sure
that
Strange. Following function runs as expected.
enum ldl_mac_status LDL_MAC_otaa(struct ldl_mac *self)
{
enum ldl_mac_status retval;
union ldl_mac_response_arg arg;
LDL_PEDANTIC(self != NULL)
if(self->ctx.joined){
retval = LDL_STATUS_JOINED;
}
else
BERTRAND Joël a écrit :
> Trampas Stern a écrit :
>> Does the code run if you comment out 'lora_send("coucou", 7);
>
> Yes. To be honnest, if I comment out LDL_MAC_otaa(), it runs.
>
>> Does it still crash with simple main() { _delay_ms(1000);
>> stty_print("hello");}
>>
>> That is start
Trampas Stern a écrit :
> Does the code run if you comment out 'lora_send("coucou", 7);
Yes. To be honnest, if I comment out LDL_MAC_otaa(), it runs.
> Does it still crash with simple main() { _delay_ms(1000);
> stty_print("hello");}
>
> That is start removing code until it works, when
David Brown a écrit :
> On 22/06/2021 18:00, Ian Molton wrote:
>> On 22/06/2021 12:59, BERTRAND Joël wrote:
>>> Hello,
>>>
>>> I'm writing a firmware for a board that uses a ATMega 1284. Firmware
>>> continuously restarts
>>
>> This is likely a branch through zero.
>>
>> Common causes on
Does the code run if you comment out 'lora_send("coucou", 7);
Does it still crash with simple main() { _delay_ms(1000);
stty_print("hello");}
That is start removing code until it works, when you find the line in main
that causes a crash, go into that function and start removing code until it
On 22/06/2021 18:00, Ian Molton wrote:
> On 22/06/2021 12:59, BERTRAND Joël wrote:
>> Hello,
>>
>> I'm writing a firmware for a board that uses a ATMega 1284. Firmware
>> continuously restarts
>
> This is likely a branch through zero.
>
> Common causes on AVR are bad function pointers,
On 22/06/2021 12:59, BERTRAND Joël wrote:
> Hello,
>
> I'm writing a firmware for a board that uses a ATMega 1284. Firmware
> continuously restarts
This is likely a branch through zero.
Common causes on AVR are bad function pointers, and stack damage.
-Ian
Trampas Stern a écrit :
> Can you comment out lines and have firmware run?
I don't understand. I have tried to comment out some lines. Sometimes
firmware runs as expected, sometimes, it continuously reboots.
When I comment out some lines or add some debug trace, firmware desn't
Can you comment out lines and have firmware run?
Could it be that your power supply is dropping and browning out?
On Tue, Jun 22, 2021 at 7:59 AM BERTRAND Joël
wrote:
> Hello,
>
> I'm writing a firmware for a board that uses a ATMega 1284.
> Firmware
> continuously restarts
22 matches
Mail list logo
