Project: SPI_MSTransfer

tonton81 · May 15, 2018

This line here, when I comment it out doesnt freeze anymore:

Code:

    if ( _available < _size ) _available++;

Then again, if available doesnt increase, neither will queue size, hmm

EDIT
While commented out, I decided to do a manual for loop on the CABUF to make sure at least memmove is doing it's job:

Code:

0 46 37444 46 0 40 60 0 0 21120 16622 0 0 21152 16622 0 0 21184 16622 0 0 21216 16622 0 0 21248 16622 0 0 21280 16622 0 0 21312 16622 0 0 21344 16622 0 0 21376 16622 0 0 21408 
0 46 37444 46 0 40 60 0 0 21440 16622 0 0 21472 16622 0 0 21504 16622 0 0 21536 16622 0 0 21568 16622 0 0 21600 16622 0 0 21632 16622 0 0 21664 16622 0 0 21696 16622 0 0 21728 
0 46 37444 46 0 40 60 0 0 21760 16622 0 0 21792 16622 0 0 21824 16622 0 0 21856 16622 0 0 21888 16622 0 0 21920 16622 0 0 21952 16622 0 0 21984 16622 0 0 22016 16622 0 0 22048 
0 46 37444 46 0 40 60 0 0 22080 16622 0 0 22112 16622 0 0 22144 16622 0 0 22176 16622 0 0 22208 16622 0 0 22240 16622 0 0 22272 16622 0 0 22304 16622 0 0 22336 16622 0 0 22368 
0 46 37444 46 0 40 60 0 0 22400 16622 0 0 22432 16622 0 0 22464 16622 0 0 22496 16622 0 0 22528 16622 0 0 22560 16622 0 0 22592 16622 0 0 22624 16622 0 0 22656 16622 0 0 22688 
0 46 37444 46 0 40 60 0 0 22720 16622 0 0 22752 16622 0 0 22784 16622 0 0 22816 16622 0 0 22848 16622 0 0 22880 16622 0 0 22912 16622 0 0 22944 16622 0 0 22976 16622 0 0 23008 
0 46 37444 46 0 40 60 0 0 23040 16622 0 0 23072 16622 0 0 23104 16622 0 0 23136 16622 0 0 23168 16622 0 0 23200 16622 0 0 23232 16622 0 0 23264 16622 0 0 23296 16622 0 0 23328 
0 46 37444 46 0 40 60 0 0 23360 16622 0 0 23392 16622 0 0 23424 16622 0 0 23456 16622 0 0 23488 16622 0 0 23520 16622 0 0 23552 16622 0 0 23584 16622 0 0 23616 16622 0 0 23648 
0 46 37444 46 0 40 60 0 0 23680 16622 0 0 23712 16622 0 0 23744 16622 0 0 23776 16622 0 0 23808 16622 0 0 23840 16622 0 0 23872 16622 0 0 23904 16622 0 0 23936 16622 0 0 23968 
0 46 37444 46 0 40 60 0 0 24000 16622 0 0 24032 16622 0 0 24064 16622 0 0 24096 16622 0 0 24128 16622 0 0 24160 16622 0 0 24192 16622 0 0 24224 16622 0 0 24256 16622 0 0 24288 
0 46 37444 46 0 40 60 0 0 24320 16622 0 0 24352 16622 0 0 24384 16622 0 0 24416 16622 0 0 24448 16622 0 0 24480 16622 0 0 24512 16622 0 0 24544 16622 0 0 24576 16622 0 0 24608 
0 46 37444 46 0 40 60 0 0 24640 16622 0 0 24672 16622 0 0 24704 16622 0 0 24736 16622 0 0 24768 16622 0 0 24800 16622 0 0 24832 16622 0 0 24864 16622 0 0 24896 16622 0 0 24928 
0 46 37444 46 0 40 60 0 0 24960 16622 0 0 24992 16622 0 0 25024 16622 0 0 25056 16622 0 0 25088 16622 0 0 25120 16622 0 0 25152 16622 0 0 25184 16622 0 0 25216 16622 0 0 25248 
0 46 37444 46 0 40 60 0 0 25280 16622 0 0 25312 16622 0 0 25344 16622 0 0 25376 16622 0 0 25408 16622 0 0 25440 16622 0 0 25472 16622 0 0 25504 16622 0 0 25536 16622 0 0 25568 
0 46 37444 46 0 40 60 0 0 25600 16622 0 0 25632 16622 0 0 25664 16622 0 0 25696 16622 0 0 25728 16622 0 0 25760 16622 0 0 25792 16622 0 0 25824 16622 0 0 25856 16622 0 0 25888 
0 46 37444 46 0 40 60 0 0 25920 16622 0 0 25952 16622 0 0 25984 16622 0 0 26016 16622 0 0 26048 16622 0 0 26080 16622 0 0 26112 16622 0 0 26144 16622 0 0 26176 16622 0 0 26208 
0 46 37444 46 0 40 60 0 0 26240 16622 0 0 26272 16622 0 0 26304 16622 0 0 26336 16622 0 0 26368 16622 0 0 26400 16622 0 0 26432 16622 0 0 26464 16622 0 0 26496 16622 0 0 26528 
0 46 37444 46 0 40 60 0 0 26560 16622 0 0 26592 16622 0 0 26624 16622 0 0 26656 16622 0 0 26688 16622 0 0 26720 16622 0 0 26752 16622 0 0 26784 16622 0 0 26816 16622 0 0 26848 
0 46 37444 46 0 40 60 0 0 26880 16622 0 0 26912 16622 0 0 26944 16622 0 0 26976 16622 0 0 27008 16622 0 0 27040 16622 0 0 27072 16622 0 0 27104 16622 0 0 27136 16622 0 0 27168 
0 46 37444 46 0 40 60 0 0 27200 16622 0 0 27232 16622 0 0 27264 16622 0 0 27296 16622 0 0 27328 16622 0 0 27360 16622 0 0 27392 16622 0 0 27424 16622 0 0 27456 16622 0 0 27488 
0 46 37444 46 0 40 60 0 0 27520 16622 0 0 27552 16622 0 0 27584 16622 0 0 27616 16622 0 0 27648 16622 0 0 27680 16622 0 0 27712 16622 0 0 27744 16622 0 0 27776 16622 0 0 27808 
0 46 37444 46 0 40 55 0 0 27840 16622 0 0 27872 16622 0 0 27904 16622 0 0 27936 16622 0 0 27968 16622 0 0 28000 16622 0 0 28032 16622 0 0 28064 16622 0 0 28096 16622 0 0 28128 
0 46 37444 46 0 40 60 0 0 28160 16622 0 0 28192 16622 0 0 28224 16622 0 0 28256 16622 0 0 28288 16622 0 0 28320 16622 0 0 28352 16622 0 0 28384 16622 0 0 28416 16622 0 0 28448 
0 46 37444 46 0 40 60 0 0 28480 16622 0 0 28512 16622 0 0 28544 16622 0 0 28576 16622 0 0 28608 16622 0 0 28640 16622 0 0 28672 16622 0 0 28704 16622 0 0 28736 16622 0 0 28768 
0 46 37444 46 0 40 60 0 0 28800 16622 0 0 28832 16622 0 0 28864 16622 0 0 28896 16622 0 0 28928 16622 0 0 28960 16622 0 0 28992 16622 0 0 29024 16622 0 0 29056 16622 0 0 29088 
0 46 37444 46 0 40 60 0 0 29120 16622 0 0 29152 16622 0 0 29184 16622 0 0 29216 16622 0 0 29248 16622 0 0 29280 16622 0 0 29312 16622 0 0 29344 16622 0 0 29376 16622 0 0 29408 
0 46 37444 46 0 40 60 0 0 29440 16622 0 0 29472 16622 0 0 29504 16622 0 0 29536 16622 0 0 29568 16622 0 0 29600 16622 0 0 29632 16622 0 0 29664 16622 0 0 29696 16622 0 0 29728 
0 46 37444 46 0 40 60 0 0 29760 16622 0 0 29792 16622 0 0 29824 16622 0 0 29856 16622 0 0 29888 16622 0 0 29920 16622 0 0 29952 16622 0 0 29984 16622 0 0 30016 16622 0 0 30048 
0 46 37444 46 0 40 60 0 0 30080 16622 0 0 30112 16622 0 0 30144 16622 0 0 30176 16622 0 0 30208 16622 0 0 30240 16622 0 0 30272 16622 0 0 30304 16622 0 0 30336 16622 0 0 30368 
0 46 37444 46 0 40 60 0 0 30400 16622 0 0 30432 16622 0 0 30464 16622 0 0 30496 16622 0 0 30528 16622 0 0 30560 16622 0 0 30592 16622 0 0 30624 16622 0 0 30656 16622 0 0 30688 
0 46 37444 46 0 40 60 0 0 30720 16622 0 0 30752 16622 0 0 30784 16622 0 0 30816 16622 0 0 30848 16622 0 0 30880 16622 0 0 30912 16622 0 0 30944 16622 0 0 30976 16622 0 0 31008 
0 46 37444 46 0 40 60 0 0 31040 16622 0 0 31072 16622 0 0 31104 16622 0 0 31136 16622 0 0 31168 16622 0 0 31200 16622 0 0 31232 16622 0 0 31264 16622 0 0 31296 16622 0 0 31328 
0 46 37444 46 0 40 60 0 0 31360 16622 0 0 31392 16622 0 0 31424 16622 0 0 31456 16622 0 0 31488 16622 0 0 31520 16622 0 0 31552 16622 0 0 31584 16622 0 0 31616 16622 0 0 31648 
0 46 37444 46 0 40 60 0 0 31680 16622 0 0 31712 16622 0 0 31744 16622 0 0 31776 16622 0 0 31808 16622 0 0 31840 16622 0 0 31872 16622 0 0 31904 16622 0 0 31936 16622 0 0 31968 
0 46 37444 46 0 40 60 0 0 32000 16622 0 0 32032 16622 0 0 32064 16622 0 0 32096 16622 0 0 32128 16622 0 0 32160 16622 0 0 32192 16622 0 0 32224 16622 0 0 32256 16622 0 0 32288 
0 46 37444 46 0 40 60 0 0 32320 16622 0 0 32352 16622 0 0 32384 16622 0 0 32416 16622 0 0 32448 16622 0 0 32480 16622 0 0 32512 16622 0 0 32544 16622 0 0 32576 16622 0 0 32608

This is correct results, so i gotta keep following the code now

defragster · May 15, 2018

yep in void fault_isr(void) - Line ~124 - #endif before while(1)

I put it there to be sure it would catch on anything undefined.

defragster · May 15, 2018

Move that if( _avail...) up to test? It might work - the memmove or something may be trashing?

Maybe in _init()?

In setup() { pinMode(LED_BUILTIN, OUTPUT);} and use this:
#define qBlink() (digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ))

Maybe tweak it like this for FLASH of 'time':
#define qBlinkF( a ) {digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ); delay (a); digitalWriteFast(LED_BUILTIN, !digitalReadFast(LED_BUILTIN) ); delay (a); }

Put that between statements with 100 or 200 or 50 delays to count and see LED flash if prints won't complete.

tonton81 · May 15, 2018

I think it's the front() pointer method:
I modded the val to be a fake value instead of reading front()
It's not stalling anymore:

Code:

                        uint16_t val = 0x5555; //= stmca.front()[ ( buf_pos > stmca.front()[1] ) ? buf_pos = 0 : buf_pos++];

ill keep digging

defragster · May 15, 2018

Odd. At least having the fault code showed it isn't triggering that. I'll make a library of that so it is more easily included.

Can you debug force a .pushfront(0x5555) and see it work - or does it fail on the .push then?

Something getting mis-ordered in compile? Is it only on T_LC or T_3.x?

tonton81 · May 15, 2018

push front wont work as 5555 isnt valid header nor crc validated

havnt tested the 3.x's, but only affects Smallest, the code actually halts the master in the process, which is even weirder, until slave is rebooted/reprogrammed/or disconnected, then master will continue to give OT errors after

EDIT, by printing this:

Code:

uint16_t val = 0x5555;
Serial.print(stmca.front()[0]); Serial.print(" ");
Serial.print(stmca.front()[1]); Serial.print(" ");
Serial.print(stmca.front()[2]); Serial.print(" ");
Serial.print(stmca.front()[3]);Serial.print(" ");
Serial.println(stmca.front()[4]);

I can see there is no issue at all with the front() method

Code:

43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 0 20 58473
43605 26 12214.00, #, #, #, #, #, #, #, #, #,959,1 [96 ,0
12224.00, #, #, #, #, #, #, #, #, #,960,1 [96 ,0
12234.00, #, #, #, #, #, #, #, #, #,961,1 [96 ,0
12244.00, #, #, #, #, #, #, #, #, #,962,1 [96 ,0
12254.00, #, #, #, #, #, #,

no lockups are occuring

tonton81 · May 15, 2018

This isn't locking up:::

Code:

uint16_t val = 0x5555;
buf_pos++;
if ( buf_pos > stmca.front()[1] ) buf_pos = 0;
val = stmca.front()[buf_pos];

old code: (this locks up on Smallest compile)

Code:

uint16_t val = stmca.front()[ ( buf_pos > stmca.front()[1] ) ? buf_pos = 0 : buf_pos++];

master/slave is no longer freezing... wtf??? whats the difference?
that code works everywhere else, except the one that uses the front() pointer

This works, but sometimes it pauses for a few secs:

Code:

uint16_t val = stmca.front()[buf_pos];
( buf_pos > stmca.front()[1] ) ? buf_pos = 0 : buf_pos++;

The first one at top doesnt seem to be pausing, from random glimpses i keep checking console
Could the compiler be hating spitefully a pointer to a multidimentional array when applying the indice to the read?
whats also weird is we shouldn't buf_pos++ before reading, otherwise the array would need to be read twice over by the master since the first stream was invalid

tonton81 · May 15, 2018

Ok, with the last file I uploaded yesturday I patched those 3 lines, seems to be okay now:

Code:

#elif defined(KINETISL)
                    while ( !((*(volatile uint32_t *)spi_mst_gpiodir_addr) & sSPI_port_gpioloop) ) {
                      if ( (*(KINETISL_SPI_t *)spi_mst_spi_addr).S & SPI_S_SPRF ) {
                        if ( (((*(KINETISL_SPI_t *)spi_mst_spi_addr).DH) << 8 | ((*(KINETISL_SPI_t *)spi_mst_spi_addr).DL)) == 0xD0D0 ) {
                          _slave_pointer->SPI_MSTransfer_Slave::stmca.pop_front(); return;
                        }
[COLOR="#0000FF"]                        if ( buf_pos > _slave_pointer->SPI_MSTransfer_Slave::stmca.front()[1] ) buf_pos = 0;
                        uint16_t val = _slave_pointer->SPI_MSTransfer_Slave::stmca.front()[buf_pos];
                        buf_pos++;[/COLOR]
                        (*(KINETISL_SPI_t *)spi_mst_spi_addr).DH = val >> 8; (*(KINETISL_SPI_t *)spi_mst_spi_addr).DL = val;
                      }
                    }
#endif

Obviously the kinetisK version is untouched, rather be tested first before I use the same patch, but ill leave the LC running for now till Mike checks it

just as a precaution since it's a pointer type, I added a cast:

Code:

                        if ( buf_pos > [COLOR="#FF0000"](uint16_t)([/COLOR]_slave_pointer->SPI_MSTransfer_Slave::stmca[COLOR="#FF8C00"].front()[/COLOR][1][COLOR="#FF0000"])[/COLOR] ) buf_pos = 0;
                        uint16_t val =[COLOR="#FF0000"] (uint16_t)([/COLOR]_slave_pointer->SPI_MSTransfer_Slave::stmca[COLOR="#FF8C00"].front()[/COLOR][buf_pos][COLOR="#FF0000"])[/COLOR];
                        buf_pos++;

Edit, I changed 5000 sec timer to 500sec, and it seems to be handling pretty well

Smallest compile report using Mike's slave code: ( with WIRE, UARTS, SPI, EEPROM defines commented out )

Code:

Sketch uses 23568 bytes (37%) of program storage space. Maximum is 63488 bytes.
Global variables use 4104 bytes (50%) of dynamic memory, leaving 4088 bytes for local variables. Maximum is 8192 bytes.

So far its running smooth

Updated file for LC lockup patch on Smallest compile option:

Code:

[ATTACH]13803._xfImport[/ATTACH]

EDIT, it's still running

defragster · May 15, 2018

Glad you found the point of pain - even if it makes no sense. Quite possible in going smallest it reordered the ternary:? evaluation and the ++ is effectively being done before rather than after use?

I think a LIB version of the UserFault() code - I had it in a sketch before I hacked that one up in yield for you to know it would catch anything - would be handy. As it is the default handler just goes to while(1) and hangs with no notice.

In your case it didn't fire - but KNOWING that tells you at least where the problem "Is Not", limiting the wonder of where to start debugging.

Really Odd that you can have 'sometimes it pauses for a few secs'! That is where a good qBlink dropped in can help locate that - even though it can be a dizzying binary flash.

tonton81 · May 15, 2018

Yeah, its just weird that only that ternary calculation was affected using the multidimensional array pointer, but not the rest of the code that uses it with local buffers..... (Smallest hates pointers i guess

)

Example: the led toggle section:

Code:

                    uint16_t val = buf[ ( buf_pos > buf[1] ) ? buf_pos = 0 : buf_pos++];

this seems to work fine as the rest of the 99% code using it

BTW, OT's still at 0 on master for LC, running 4MHz with transfer16's set at 5uS gaps, and 10uS F&F sendings

defragster · May 15, 2018

Looking at post 1632 code the first block is equal to this - not what is in the second block?

Code:

uint16_t val = stmca.front()[ ( [COLOR="#FF0000"]++buf_pos[/COLOR] > stmca.front()[1] ) ? buf_pos = 0 : [U][B]buf_pos[/B][/U]];

tonton81 · May 15, 2018

1632:

Code:

uint16_t val = stmca.front()[ ( buf_pos > stmca.front()[1] ) ? buf_pos = 0 : buf_pos++];

This looks fine, buf_pos is incremented through the while loop while sending the data to the master, as long as it's not higher than the length "[1]", it's incremented..

is it possible it's incrementing past the buffer when updating val?

EDIT, just tried yours #1636, froze....
EDIT, rolled back to patch and its working fine, I guess we can leave it like this

EDIT, as a sanity test I mass replaced the lib other ones like post #1635 to your version as well, it crashed as well. So I reloaded back the working library again

Maybe "Smallest" is really broken

defragster · May 15, 2018

I should have said 'More Like' because you start the code block with the ++ then test if it went over and set it to 0. I quickly assumed that was the point of the ternary and posted then had to run

Code:

uint16_t val = 0x5555;
[COLOR="#FF0000"]buf_pos++;[/COLOR]
if ( buf_pos > stmca.front()[1] ) buf_pos = 0;
val = stmca.front()[buf_pos];

mjs513 · May 15, 2018

Hi all. Got back from my excursion a little while ago. Wow. What the heck. A lot happening since I left, not sure where even to start.

Guess I use the SPI_master in post 1613 and SPI_slave in post #1633. No changes to core modules needed now correct? Would surprise me that smallest is not working in this case. Not sure if using the nano libc causes the issue: https://forum.pjrc.com/threads/4086...lchain-Update)?p=127807&viewfull=1#post127807.

Tim - like you idea to make the UserFault a library. Nice one on that.

Mike

tonton81 · May 15, 2018

yes use the master from #1613 and slave from #1633, if your using LC, i recommend you put a 5uS delay in the 2 new internal transfer16 functions and run LC at 4MHz, its been running here all day and since last night at 0OT’s, and still running now with 0OT’s

the 2 new transfer16 functions are used as opposed to core version to gain more control over the sending, you can search the master’s CPP file for “::_transfer”, theyre back to back, youll see one with 1uS delay, change it to 5 and duplicate it to the other, youll be having no OT errors at 4mhz, only intermittant at 8, and yeah, slave is sending traffic to master in 500ms rates working fine since morning

mjs513 · May 15, 2018

Ok. Change made Yes at 4MHz and 4Khz working no problem. Yes 2way working, think its your 500ms chucks: https://youtu.be/ZuA87DjgILk. Think this what you mean. I will do some more testing later and keep you posted. Crazy things going on with the LC. Beginning to wonder if its worth making it work in master mode. Anyway will retest with the 3.2 as well. Diner is calling.

tonton81 · May 15, 2018

no pauses here, i think master is still set at 4mhz f&f, 300khz other, both ::_transfers have 5uS delay

Yup, master at 4MHz F&F, 300KHz rest, 10ms loops
Slave's doing 500ms transfers, using SPI0

https://www.youtube.com/watch?v=tZXAnu7KvF8

mjs513 · May 15, 2018

I'm on SPI1, but would that make a difference? 300Khz was the same... pause before receive/send

tonton81 · May 15, 2018

shouldnt be difference, as long as you added the uS delays to master it should be fine
im using pin0 as ground for spi0, no pauses, ill try spi1....

EDIT: OK, it was being real finicky, but it was my wiring, im pushing down on the jumpers and its running stable, ill try to make a video using begin(SPI1)...

mjs513 · May 15, 2018

That's on the LC side - was going to change to SPI to check

tonton81 · May 15, 2018

OK, SPI1 is working, but the cabling like I said is flimsy, heres the proof:

https://www.youtube.com/watch?v=0A50t59qH6M

Yeah, this is on slave

EDIT: Swapped back to SPI, its running good.

mjs513 · May 15, 2018

I believe you - just tried SPI and didn't work - going to recheck wiring again

Then will go back to SPI1 - maybe its a wiring problem on my side as well.

tonton81 · May 15, 2018

2, 11, 12, 14, but if it doesnt work, try swapping 11 and 12

perhaps I should label them as well as not just give 4 pins on startup console
perhaps ill do:

LC

Code:

    Serial.println("SPI Slave pins connections: CS(2), MOSI(11), MISO(12), SCK(14)");
    Serial.println("SPI1 Slave pins connections: MOSI1(0), MISO(5), CS(6), SCK(20)");

3.x

Code:

    Serial.println("SPI Slave pins connections: CS(2), MOSI(11), MISO(12), SCK(14)");
    Serial.println("SPI1 Slave pins connections: MOSI(0), MISO(1), CS(31), SCK(32)");
    Serial.println("SPI2 Slave pins connections: CS(43), MISO(51), MOSI(52), SCK(53)");

EDIT, I added those changes now for both kinetis K and L series

Judging that SPI master is working for you, and your not on SPI2 like me, I can only assume my dynamic bus addressing is working on your end, otherwise the transfer16's wouldnt be working at all

Code:

  if ( SPIWire == (SPIClass*)&SPI ) _spi_port_memorymap = 0x4002C000;
  if ( SPIWire == (SPIClass*)&SPI1 ) _spi_port_memorymap = 0x4002D000;
  if ( SPIWire == (SPIClass*)&SPI2 ) _spi_port_memorymap = 0x400AC000;

mjs513 · May 15, 2018

perhaps I should label them as well as not just give 4 pins on startup console perhaps ill do:

Yep. I went in to make sure I did it right.

By the way I am seeing the same thing, with the start/stops on the SPI as well with the T3.5/LC. I did what you did with playing around with the wires but no difference. The only thing left would be to go find my bread board wires as a double check.

tonton81 · May 15, 2018

weird its only ur side, my host is a t3.6, i didnt modify your master/slave examples other than the SPI begin portion of the slave, i leave it running here still with 0OTs, no pauses, and slave error counter hasnt increased at all either

are you using Smallest or Fastest for compile? Tried both? I'm testing Smallest currently

Just uploaded compiled as Fastest and still no issues

Project: SPI_MSTransfer

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Well-known member

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member

Senior Member+

Well-known member