Re: Mutex oddities with v1.0.0

> > > t_obj is only used when waiting for lock, to link the tasks which are > waiting > for the lock. Not after lock has been obtained. > Task can only sleep on one lock at a time; it’s not possible to wait for 2 > simultaneously. > So semaphore and mutex using the same t_obj while waiting is ok;

Re: Mutex oddities with v1.0.0

> On Nov 6, 2017, at 5:23 PM, Jitesh Shah wrote: > > Alright, > I think I have an idea of whats going on here. > > So the structure of my code is like this -> > os_mutex_pend(); > .. trigger operation here .. > os_sem_pend(); // Wait for operation to complete. ISR calls

Re: Mutex oddities with v1.0.0

Jitesh: You are indeed correct: the current code will not allow that. This will be addressed in the 1.3 release. Thanks for pointing this out! Will > On Nov 6, 2017, at 5:23 PM, Jitesh Shah wrote: > > Alright, > I think I have an idea of whats going on here. > > So the

Re: Mutex oddities with v1.0.0

I’d start by looking for memory corruption. You could try adding guard variables around your send_mutex(), and see if anything stomps on them. Another option could be to change mutex_release() to write something other than 0 at mu_owner, and then add a conditional hardware watchpoint which looks

Re: LoRa power consumption

Marco: Not sure if you are referring to the current mynewt LoRa implementation or LoRa in general. The Semtech SX1276 chip draws 11-12mA in receive mode. The processor will add to this of course. If you are asking about mynewt specifically the current drain has not been measured but there are

Re: Mutex oddities with v1.0.0

I agree that a mutex should never have a null owner and a nonzero level. Unfortunately, my first guess is some form of memory corruption: it seems like a null value accidentally got written to `mu_owner`. I could be missing it, but I don't see any logic error in the mutex code which could cause

LoRa power consumption

Hi everyone! Does any of you have an idea what's the power consumption for Rx with LoRa? Thanks -- Marco

Re: Mutex oddities with v1.0.0

What this looks like to me is that there was a nested pend without the same number of releases. Maybe some path out of some code that is rarely hit where a mutex is granted but not released? Just a guess... > On Nov 5, 2017, at 8:26 PM, Jitesh Shah wrote: > > Hey Guys,