Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Serial.setup() with options for bytesize, parity and stopbits cause ASSERT(0) #1510

Closed
MaBecker opened this issue Sep 16, 2018 · 12 comments
Closed

Serial.setup() with options for bytesize, parity and stopbits cause ASSERT(0) #1510

MaBecker opened this issue Sep 16, 2018 · 12 comments
Labels
ESP8266 This is only a problem on ESP8266 devices

Comments

@MaBecker
Copy link
Contributor

Serial2.setup(9600,{rx:D12,tx:D13,bytesize:8,parity:'none',stopbits:1});

ASSERT(0) FAILED AT targets/esp8266/jshardware.c:833
  #1[r1,l2] Object {
    #2[r1,l2] Name String [1 blocks] "\xFF"      #3[r1,l1] Object {
....
507089> ASSERT FAILED AT targets/esp8266/jshardware.c:833
---console end---
507095> CRASHING. 
507097> Fatal exception 9(LoadStoreAlignmentCause):

Serial2.setup(9600,{rx:D12,tx:D13}); works fine and can be used because 8 none 1 is default.

The structure JshUSARTInfo is not corrected handled on ESP8266 in jshUSARTSetup

changing unsigened char to unsigned int fixes this on ESP8266 what about side effect on other devices?
@MaBecker MaBecker added the ESP8266 This is only a problem on ESP8266 devices label Sep 16, 2018
@gfwilliams
Copy link
Member

changing unsigened char to unsigned int fixes this on ESP8266

On all elements of JshUSARTInfo ?

I'm not sure I understand what's going on here - maybe you could print the contents of every element in JshUSARTInfo?

If ESP8266 is unable to read/write from an unsigned char in a struct then that's something that needs sorting with compiler flags, as while we could patch over this one, there are hundreds of other points that this coulkd fail in the future?

@wilberforce
Copy link
Member

This isn't a flash alignment issue is it? - the structure would be in ram.

@gfwilliams
Copy link
Member

gfwilliams commented Sep 18, 2018 •
edited

Yeah, should be - so I wonder why the LoadStoreAlignmentCause?

Although I guess that happens after the assert anyway

@MaBecker
Copy link
Contributor Author

This is not the first time that a structure cause LoadStoreAlignmentCause
happend for jshI2CSetup too and was fixed by reordering the entries.

Serial2.setup(9600,{rx:D12,tx:D13}); works, so this is ok for ESP8266.

Using typedef struct { } will always fail on ESP8266 for one byte entries.

@gfwilliams
Copy link
Member

Using typedef struct { } will always fail on ESP8266 for one byte entries.

Seriously? That sounds like a pretty serious issue - are you sure there aren't compiler flags we could turn on? Or what about that LoadStoreAlignment exception handler - that'd be perfect for stuff like this since it happens so rarely.

@gfwilliams
Copy link
Member

I guess we could have a PACKED_FLAGS_MAYBE thing where it was enabled for all platforms except ESP8266 - I don't have time right now to figure out what would be affected on other platforms if we removed the packing completely.

@MaBecker
Copy link
Contributor Author

Thanks Gordon, will run some test with different typedef struct{} and compiler flags.

@MaBecker
Copy link
Contributor Author

MaBecker commented Nov 1, 2018 •
edited

I guess we could have a PACKED_FLAGS_MAYBE ....

What do you mean @gfwilliams?

@gfwilliams
Copy link
Member

Rather than having even more #ifdef ESP8266 we have PACKED_FLAGS_MAYBE which is defined in jsutils.h like PACKED_FLAGS, but which does stuff for all platforms except ESP8266.

PACKED_FLAGS_MAYBE is a bad name - I'm open to better suggestions

@wilberforce
Copy link
Member

how about PACKED_FLAGS_MABECKER ;-)

On a serious note there must be compiler flag for this.

@MaBecker
Copy link
Contributor Author

MaBecker commented Nov 2, 2018

Sounds funny, had no idee that it is defined jsutil.h

So let me check gcc flags and run some tests.

@MaBecker
Copy link
Contributor Author

MaBecker commented Nov 3, 2018 •
edited

On a serious note there must be compiler flag for this.

Do you mean -mforce-l32
Use l32i to access 1- and 2-byte quantities in
memory instead of l8ui/l16ui

If Yes, it is implemented for ESP8266_4MB builds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ESP8266 This is only a problem on ESP8266 devices
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gfwilliams @wilberforce @MaBecker