RADDS work now stable with RepRap Firmware

So I've bought a Due from China recently and it was not working with RepRapFirmware (in fact, with any other firmware too). It was giving me -55 degrees on all thermistors and nothing else. So I managed to fix it and here's how:
I've put a potentiometer on A0 pin as described here and turned it a few times. At about half the way to 100% it started to give me 1023 (aka maximum) – that can't be right. Looked totally like if reference voltage was ~50% lower than 3.3V. Putting 3.3V on AREF pin gave no result: apparently to provide your own reference voltage to Arduino Due you have to de-solder a jumper resistor and solder it in other position.
Here's the catch: that jumper resistor should be 0 Ohm, but on that chinese board it was ~3.5 Ohm!
The solution is to replace it with a solder blob/trace.
It is so freaking tiny you have to be really careful not to inhale it when you solder it. Here's a picture of my amazing soldering skills to give you an idea where to look for that little fu**er.

Now, everything works correctly. Lesson: buy original (or have a pointy soldering iron).

Well done toxuin, I had the same issue with a DUE board bought from reprap.me.

Many thanks to mandrav for his solution on third page; I love you man, it was driving me crazy!!!

Excluding the Micro stepping options, is there any advantage of switching to RAPS128, such as getting more out of the 3.3v from the Due?

... they can be run with higher currents for better coolers ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
VDX
... they can be run with higher currents for better coolers ...

I not sure I would be able to leverage that higher current, I have 1.3A motors and cant even reach the VREF voltage of 0.83VDC, all my A4988 drivers top out around 0.78VDC due I assume to the 3.3V of the Due?

It's best to run stepper motors at no more than about 85 or 90 percent of their rated current, to avoid overheating them. So that extra 0.05V you are missing isn't worth having given that you have 1.3A motors. But you can also get higher current A4982 or A4988 boards with 4 layer PCBs and 0.05 ohm sense resistors, which can provide a little more current than the drivers you have.

The nice thing about the RAPS128 drivers apart from the microstepping is that the chips on them are designed to be cooled from the top, so the heatsinks on them actually work.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

... I'm driving NEMA-23 steppers, rated for 1.5A, with the RAPS128 drivers set to 0.8A just fine with speeds of up to 400mm/s

They can be driven without problems with 1.5A, when cooling with forced air ... for up to 2A I'm clamping a bigger aluminium cooler across the three RASP-coolers to spread the heat and distribute it to the outer housing of my dispensers ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Thanks Viktor & DC42

My 5" LCD module arrived today.
Did a small test using RADDS + RADDS LCD + PanelDUE - RADDS running Repetier firmware.
Communication ok, and the values on the RADDS LCD changes when "moving" the axis using the PanelDUE

I`m going to test it in combination with Repetier and RepRap firmware

Anyone tested connecting using a Bluetooth link and added a battery? Using it as a remote-control/monitor

Hi guys , Im building my first printer and I got a serious problem with the radds and firmware 1.09r, its about the sd card making the firmware hang

I try many cards , I even hook a glcd with a full size reader to try more cards. My due is a r3-e original, The radds a brand new one V1.5 from makerfarm and I can access the sd card with it if I connect WITHOUT the card first and can see it with m503 but when I ask the firmware to exec it (m98 Pconfig.g) it hang , just like when the firmware boot and try to read it. I try to reduce the content of the config.g to only the name of the machine and it still hang and I also try many stock config without changing anything ... same result.

If you guys can look into it, specially dnewman it will be great, here the thread where I explain everything in details:


My thread

PS: Just tried the 1.09K-B and its connecting , see the config, and moving so far, the problem is related to the 1.09r... I am the only 1.09r tester ?

Edited 1 time(s). Last edit at 02/23/2016 06:14PM by GroupB.

I'm using 1.09r on RADDS and the on-board uSD works fine for me. Do not use the LCD display + SD card. It's not yet supported. Not even the SD slot on the LCD display -- it doesn't work with RRF on RADDS. (I'm not sure why; I've not had a chance to look into it.) So, disconnect the LCD display and external SD.

Oh I said I used the GLCD as secondary Sd card to test out, because plugging only a micro into the radds slot did not work and I did not plug both card at same time, I dont have it hook all the time , Just one time for testing and I redid all the wiring to match the radds just in case its suported in near futur.

I now get movement and it read config with 1.09k, but 1.09r is a no go for me , load it 4 time via native ( erase,reset) the programing port instruction do not work on my due r3-e, its stay as COM programing port in device manager and the bossac command line wont work on that COM.

Do you have a original r3-e for testing ? maybe the problem coming from that revision of the due with 1.09r, if someone with a r3-e can test out too it will be great

if it in fact because of the arduino rev r3-e well... my decision to pay more to get a original to avoid problem was a bad one.

So Arduino original R3-e ( beige connector) + Radds v1.5 brand new from makerfarm

My RADDS 1.5 board with the public 1.09r-dc42-radds build is reading the uSD card just fine with no issues. So, this isn't a problem I can reproduce.

Wondering why my radds 1.5 and r3-e wont work then , what are the change touching the sd card between 1.09k-b and 1.09r? There must be something...

Without the sd card in the radds the firmware was responding to my command but as soon as I put a card and execute it, the firmware hang. It also happen with a very minimal config.g .. Like the name of the machine only. Happen with 7 different sd card.

I hope the community can find the problem , or someone can reproduce my firmware hang. Or I will be stuck on 1.09k forever without any update possible in the futur.

Quote
GroupB
Wondering why my radds 1.5 and r3-e wont work then , what are the change touching the sd card between 1.09k-b and 1.09r? There must be something...

Without the sd card in the radds the firmware was responding to my command but as soon as I put a card and execute it, the firmware hang. It also happen with a very minimal config.g .. Like the name of the machine only. Happen with 7 different sd card.

There were many, many changes. However very few specific to RADDS.

With RepRapFirmware, you should not be removing and re-inserting the SD card while the board is powered on. The card is expected to be present at boot time for config.g and you're not supposed to remove it. If you do remove it, you need to reboot.

There is code present (for RADDS at least) which will react to the SD card detect switch triggering. However, there is no SD card detect switch on the RADDS v1.5 board. The GPIO line for it is pulled low (IIRC).

I know the card need to be there at boot , but I was doing some test and dc 42 advice me to try to boot it without card and then do a m503 to check if the card read and then a m98 p config.g to load the config, but it hang like at boot with sd card.

Ill look into the shematics again but if i remember the socket is wire to the cd switch and to a pin on the due. Maybe my radds have a default there or a change in assembly , ill check.

So between k and r there was a change specific to the cd pin?

There is a cd switch on my socket and like you said it pull the pin to gnd when a card is inserted, that pin is hook to pin 14 on the due (tx3). So far normal beheviour?

I'd swear that the SD detect switch doesn't even function on my two RADDS 1.5 cards and always appears as though a card is present.

There is an interrupt which fires whenever the SD detect switch changes state. And the internal pullup resistor on the ARM chip is asserted to ensure that the signal isn't floating. However, you may have a switch which is bouncing constantly and causing that interrupt to continually fire. Or some other subtle issue with the interrupt. I'll try to build you later today a build with the interrupt disabled which you can then try.

Thank man , I apreciate it. If it fix it you will probably avoid other user problem in the futur.
My radds is a 1.5 but its kinda new batch, makerfarm was waiting on that shipement 2 week ago and I order it as soon as they receive it. If all makerfarm batch is like that the next few North American guys will probably have the same prob.

There no hurry, take your time... I dont have a fonctionnal printer,im missing a z probe before I can get into it.

Drop me a note -- PM me -- with your e-mail address and I'll send you a build of 1.09r-dc4-radds with the SD CD interrupt disabled. I just built it and tested it on my printer to ensure that SD reads still work. (They do.)

The sole change to the source to disable is

diff --git a/src/MassStorage.cpp b/src/MassStorage.cpp
index 9fda719..ba2a04b 100644
--- a/src/MassStorage.cpp
+++ b/src/MassStorage.cpp
@@ -18,7 +18,7 @@ MassStorage::MassStorage(Platform* p) : platform(p)
        Reset();
 #if defined(SD_DETECT_PIN) && defined(SD_DETECT_VAL)
        pinModeNonDue(SD_DETECT_PIN, INPUT_PULLUP);
-       attachInterrupt(SD_DETECT_PIN, SdCardDetectInterrupt, CHANGE);
+       // attachInterrupt(SD_DETECT_PIN, SdCardDetectInterrupt, CHANGE);
 #endif
 }

Thanks for trying dan , but it did not work, I got the same beheviour as 1.09r. firmware just hang and wont connect because it look too busy, I recv nothing from the controller in terminal. It connect without the sd card and complete the boot...

There something it does at boot that hang but I cant have terminal access , is there a way to hook something to debug it and know what is causing this ?

It is a possibility that there something with the EEPROM causing this ? since I guess with a working firmware the code it read from SD go there right ?

Edited 1 time(s). Last edit at 02/24/2016 06:05PM by GroupB.

Well, when I need to do serious debugging, I put in a slight startup delay so I can get a terminal window connected to the serial I/O. I also build with asst. debugging enabled.

Will it startup and not hang with an empty config.g file in sys/ ?

Also, issue a M115 command to ensure that the build you have installed is indeed dated 2016/2/24 (2016-February-24). For me at least, I sometimes make a mistake and install and old binary

Edited 1 time(s). Last edit at 02/24/2016 07:06PM by dnewman.

It hang even with an empty file , as soon as it see a config.g file, its pass if there no file at all

But there one thing I was about to do is to load without a sd , then put in the sd and do a m503 and it report the config but you cannot execute it m98 Pconfig.g or it hang, you can move the printer and it respond to command but you cant execute the file.

Im not a firmware genius , my coding go as far as arduino sketch but will it be helpful to know the step the due do when there is no sd and then when there is a sd .. The problem lie there in the step it skip when there is no sd ... My guess.


There some debug connector on the due I think ( really small pin) I never debug anything but if its simple a building some kind of circuit and hook an arduino to it or connect via i2c or spi maybe, I may be able to see what the hang is about.

Ps: I already reflash the working k but im sure I load the right file because I always move the bin I want to a folder before flash your was 1.09r-a-dc42

Edited 1 time(s). Last edit at 02/24/2016 07:19PM by GroupB.

Quote
GroupB
It hang even with an empty file , as soon as it see a config.g file, its pass if there no file at all

So, it's fine if the SD card is present, has the sys/ folder, but just lacks a config.g file? You sure these sd cards are formatted FAT-16 or FAT-32 and not eFat? (eFat is the default on Windows these days.) That the firmware can init the SD card, access the first partition, read the root directory, and access the sys folder but not be able to process the contents (even if none) of config.g sounds like the SD card is working at several levels. It's more suggestive of an issue following file block chains or something along those lines.

Quote

But there one thing I was about to do is to load without a sd , then put in the sd and do a m503 and it report the config but you cannot execute it m98 Pconfig.g or it hang, you can move the printer and it respond to command but you cant execute the file.

SD card has to be present at boot. There's no putting it in post boot and then accessing it. That's the point of the interrupt I disabled in the build I sent you. It's an interrupt that, for a working SD CD switch, will note that the card has been removed or inserted and re-initialize the file system. But right now, you have nothing which detects insertion of the card and re-inits the file system. So, if initialization failed at boot, you do not get any SD card access post boot.

Quote

There some debug connector on the due I think ( really small pin) I never debug anything but if its simple a building some kind of circuit and hook an arduino to it or connect via i2c or spi maybe, I may be able to see what the hang is about.

That's not relevant here.

BTW, between 1.09k and 1.09r there were both changes to the underlying SD card libraries AND perhaps more importantly use of directl memory access (DMA) to speed up SD card access was added. The DMA is working fine for me with genuine Arduino Due boards. Are you using a genuine Due board or one of the Asian clones? The Asian clone Due boards have "issues". While I don't know specifically of an issue with DMA, I don't put a lot of faith in these clone boards either. And, since the same SD card works for you with 1.09k but not 1.09r, I'd bet money that it's the DMA.

Genius original due r3-e ( the fixed version , for the power problem with the 16U chip) it also had beige connector on it. Maybe arduino did something else with the e version, I dont know... but since I use the native port to connect it should not go through the 16U chip yes ?
Please note that also I have to use bossac with erase and reset to load firmware, I cant load it via programing port like your instruction on the /dev/doc/radds.md. I wonder if its the same for all the r3-e user
All the 7 cards I try were fat32 and some I even try fat 16 while reducing the partition via windows DISKPART

Is there some kind of test I can do to make sure the DMA work find on the due ? like an simple arduino Sketch I can load as a test, testing one component at the time kind of ?

Edited 3 time(s). Last edit at 02/25/2016 06:47AM by GroupB.

Dan, are you certain that you picked up my changes to the FatFs library to ensure that all physical reads and writes are done on 32-bit boundaries? The DMAC in the sam3x8e doesn't work properly if you ask it to do unaligned transfers. I am wondering whether something in the hardware configuration could cause the software to change the location at which a buffer is allocated.

The fact that M503 works as expected suggests that the DMA is working at least some of the time.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Im trying to find the diff between the r3 and the r3-e and there not a lot of info about that, except that the power problem is now fix

Plz note that my arduino is not made but Arduino.CC but by Arduino.org

those are the "I think" the code of the fix for E version, found on arduino.org

AVR and SAM git

They talk about serial flush think, I have no idea what that mean but maybe that something

Edited 2 time(s). Last edit at 02/25/2016 08:07AM by GroupB.

Quote
dc42
Dan, are you certain that you picked up my changes to the FatFs library to ensure that all physical reads and writes are done on 32-bit boundaries? The DMAC in the sam3x8e doesn't work properly if you ask it to do unaligned transfers. I am wondering whether something in the hardware configuration could cause the software to change the location at which a buffer is allocated.

My certainty is only as good as my trust of "git pull". That is, they were pulled provided git pull did its job. I'll diff the actual files in Libraries/SD_HSMCI/ later today to ensure that the changes were all obtained. (I do not exercise any selection over the changes I merge in: I merge them all in, putting my faith in git. I will add that I do not have 100% confidence in git nor myself.)

Edited 1 time(s). Last edit at 02/25/2016 10:58AM by dnewman.