initial ksz8851snl driver files for Ethernet XPRO expansion #4212
Conversation
|
@poppe34 Nice fix on NETOPT 26. I think that jdebug (https://github.com/poppe34/RIOT/blob/6b1576b12422af0b24e2562d4a8f8f61d954d83b/boards/samr21-xpro/dist/samr21.jdebug) is just a file specific to your IDE? As such it should be excluded from the PR, I think. You may find it convenient to add it as a .gitignore rule(?) |
|
I will take it out and I won't add it anymore. It is for my debugger with jlink. |
|
:) ok, I also have a copy of your PR here with a SAMR21 + Ethernet1 and I'd like to help you track down this mutex issue if I can. |
|
So here's something interesting. I tagged the mutex functions inside static void lock(ksz8851snl_t *dev) {
DEBUG(SECT_NAME "Locking Mutex.\n");
mutex_lock(&dev->mutex);
}
static void unlock(ksz8851snl_t *dev) {
DEBUG(SECT_NAME "Unlocking Mutex.\n");
mutex_unlock(&dev->mutex);
}But I've never seen an unbalanced pair! Every lock is followed by an unlock, an yet the |
| @@ -0,0 +1,254 @@ | |||
|
|
|||
There was a problem hiding this comment.
Not sure for what you included this file? Also seems unrelated to this PR?!
There was a problem hiding this comment.
Yeah I pointed that out as well, @poppe34 said it's from his debugger & he will be removing it.
haukepetersen
added
Area: network
|
|
||
| #define SECT_NAME "[KSZ8851 Driver]:" | ||
|
|
||
| static void lock(ksz8851snl_t *dev) { |
There was a problem hiding this comment.
please move the opening '{' to the next line -> RIOT coding conventions
There was a problem hiding this comment.
also makes sense to inline this function, but might be that the compililer does this anyway...
|
msolters I did the exact same thing. I even took out the locks all together and it still got locked in the mutex. I have been digging into the issue and the only area that I see that locks a mutex is in the pktbuf. So I am looking for an area that gets locked but doesn't get unlocked. I might try the same method we did in the driver, but I am running out of time today.. haukepetersen: I will roll your comments into my code. I did auto init just like the: auto_init_at86rf2xx.c just thought there could better way since the config file is with the driver and other config files tend to be in the board directory. So each board can have their own config, but there is other ways that could be done. |
|
In an effort to debug this further, I set 2015-11-02 16:43:20,131 - INFO # [KSZ8851 Driver]:Locking Mutex.
2015-11-02 16:43:20,134 - INFO # gnrc_ksz8851snl: trying to get mutex. val: 0
2015-11-02 16:43:20,138 - INFO # gnrc_ksz8851snl: trying to get mutex. val: 0
2015-11-02 16:43:20,142 - INFO # gnrc_ksz8851snl: trying to get mutex. val: 1
2015-11-02 16:43:20,145 - INFO # gnrc_ksz8851snl: Mutex in use. 1
2015-11-02 16:43:20,150 - INFO # gnrc_ksz8851snl: Adding node to mutex queue: prio: 3
2015-11-02 16:43:20,152 - INFO # mutex_unlock(): val: 1 pid: 6
2015-11-02 16:43:20,153 - INFO #
2015-11-02 16:43:20,155 - INFO # Context before hardfault:
2015-11-02 16:43:20,156 - INFO # r0: 0x200058c4
2015-11-02 16:43:20,158 - INFO # r1: 0x0000e779
2015-11-02 16:43:20,159 - INFO # r2: 0x00000400
2015-11-02 16:43:20,161 - INFO # r3: 0x00000006
2015-11-02 16:43:20,163 - INFO # r12: 0x0000001d
2015-11-02 16:43:20,164 - INFO # lr: 0x000008bb
2015-11-02 16:43:20,166 - INFO # pc: 0x000008dc
2015-11-02 16:43:20,167 - INFO # psr: 0x21000014
2015-11-02 16:43:20,168 - INFO #
2015-11-02 16:43:20,168 - INFO # Misc
2015-11-02 16:43:20,170 - INFO # EXC_RET: 0xfffffff1
2015-11-02 16:43:20,174 - INFO # Attempting to reconstruct state for debugging...
2015-11-02 16:43:20,174 - INFO # In GDB:
2015-11-02 16:43:20,176 - INFO # set $pc=0x8dc
2015-11-02 16:43:20,177 - INFO # frame 0
2015-11-02 16:43:20,177 - INFO # bt
2015-11-02 16:43:20,177 - INFO #
2015-11-02 16:43:20,181 - INFO # ISR stack overflowed by at least 104 bytes.Unfortunately I don't fully understand where this ISR stack is being initialized; where would I be able to assign more stack space to this process to continue debugging? |
|
the stack space is initiated in the auto_init file inside sys/auto_init/netif/auto_init_ksz8851snl |
| ksz8851snl_t * dev = (ksz8851snl_t*)encdev; | ||
|
|
||
| lock(dev); | ||
| for (uint8_t x = 0; x < 6; x++) |
There was a problem hiding this comment.
nicer to read with s/6/ETHERNET_ADDR_LEN/
|
Any news? |
|
Needs rebase and adaption to #4871. |
|
WIP -> postponed. |
|
Feature freeze -> postponed. But would be happy to finally have this merged come January 😃. |
|
We really should try to get it in for the release. I would volunteer to be the shepherd if someone could give me the hardware. |
|
I think I have one of these in my desk drawer in the office. |
|
@miri64 did you find one in your desk drawer? |
OlegHahm
added
the
Community: Hack'n'ACK candidate
|
Japp :-) |
|
(and delivered) |
|
@OlegHahm do you still think this is realistic for the upcoming release? |
|
Since I don't have time to test this today, unfortunately not. |
|
Ping? |
|
Since there was no real activity on this PR for > 6 month, I would actually go ahead and close this as memo. |
|
Reopen if you disagree. |
miri64
added
the
State: archived
Ok... Here is the new fork from the previous fork that I made. This will allow for communication to the Atmel Ethernet Xpro on the SAMR21 Board. I do have plenty of bugs in this but I am hoping people can help me squash them. I will be working on correcting the big flaw that it currently has with somehow freezing the UART.