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.

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

Realtek_RTL8195AM fix for debug profile #5044

Merged
merged 5 commits into from
Sep 19, 2017

Conversation

Archcady
Copy link
Contributor

@Archcady Archcady commented Sep 7, 2017

Previously Realtek_RTL8195AM is unable to run with debug profile, now the issue is resolved. Changes are:
Change MSP setting method in booting;
Update wlan libs to fix a mutex osErrorISR issue;
Increase tcpip thread stacksize;

Related PR:
#4665

Use asm code to set MSP
The issue of mutex returning osErrorISR with debug profile is fixed
The default stack size is not enough for debug profile (low compiler
optimization)
Clean rtl8195a_init.c a little bit
@Archcady
Copy link
Contributor Author

Archcady commented Sep 7, 2017

Hi @marcuschangarm , we fix the issue with debug profile with GCC on windows. I'm not sure if the issue with ARMCC/Linux is fixed since we don't have the compiler. Would you please give this PR a quick test? Many thanks.

Copy link
Member

@bulislaw bulislaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@marcuschangarm
Copy link
Contributor

@Archcady Thank you for the fix. My test app is currently too large when using debug profile, so it might take me some time to shrink the test app enough to test this.

@0xc0170
Copy link
Contributor

0xc0170 commented Sep 8, 2017

@Archcady Thank you for the fix. My test app is currently too large when using debug profile, so it might take me some time to shrink the test app enough to test this.

Any estimate?

@marcuschangarm
Copy link
Contributor

Well, good news, bad news. 😄

I'm not seeing the problems I saw when compiling with debug profile. So thats great!

Overall, I'm still seeing a lot of instability issues. My TLS client test connects successfully 50% of the time, the other times it fails on a socket error.

When I run my large application, it crashes at random places.

I'm also seeing this odd warning when linking:

Link: tls-client
Elf2Bin: tls-client
Malformed input found when parsing GCC map: linker stubs
Malformed input found when parsing GCC map: linker stubs

@Archcady
Copy link
Contributor Author

Hi @marcuschangarm , those strange messages (Malformed input found when parsing GCC map: linker stubs) are coming from mbed-os\tools\memap.py. Looks like the MemapParser could not parse all the lines in .map file. The same messages are found when compile with ARMCC.

Remove intermediate variances and use uint64 instead;
Remove HalTimerIrqEn called in us_ticker.c
@Archcady
Copy link
Contributor Author

Hi @marcuschangarm , with this new commit, mbed-cloud-client-example-r-confidential is much stable now. I ran it for at least one hour without crash or hanging.

@marcuschangarm
Copy link
Contributor

Thank you! That is great news! I'm currently traveling, but I'll try it out as soon as I get back!

@adbridge
Copy link
Contributor

/morph test-nightly

@mbed-bot
Copy link

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test-nightly

@studavekar
Copy link
Contributor

/morph test-nightly

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1338

All builds and test passed!

@adbridge
Copy link
Contributor

@0xc0170 there was another change since you last reviewed, could you take a quick re-review?

Copy link
Contributor

@adbridge adbridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of minor coding style issues which should be fixed in any subsequent PR but not going to block this one on them.

@@ -23,24 +23,33 @@
#define SYS_TIM_ID 1 // the G-Timer ID for System
#define APP_TIM_ID 6 // the G-Timer ID for Application

#define TICK_TO_US(x) (uint64_t)(((x)/2) * 61 + ((x)%2) * TIMER_TICK_US)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An explanation of where '61' comes from would be useful here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adbridge Clock source is 32K, therefore, us per tick is 30.5. The TICK_TO_US macro is basically: (tick / 2) * (30.5*2) + residue

This patch is basically broken. I have submitted another PR #5143 to address us ticker issue, and also added proper inline comment.

}

void us_ticker_init(void)
{

if (us_ticker_inited) return;
if (us_ticker_inited){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

space required before '{'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also fixed in #5143

@adbridge adbridge merged commit 003dd7c into ARMmbed:master Sep 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants